Re: File Encapsulation Quandary

"with SQL is usually a bad idea since SQL isn't conductive to
record at a time operations"

Based on my experience I believe this is a myth. We have hundreds of
programs doing single I/O operations using SQL and I have yet to see
any real problem. You might do a test and have a few milliseconds
slower but in a real world environment does that really matter?

On Wed, Apr 4, 2012 at 2:14 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

I'm with Scott, the only reason to encapsulate a file is to
encapsulate business logic with the file i/o...  Your example is a
perfect example of this.   Even the simplest logic can/should be
encapsulated...I once had a master file with an active/inactive flag.
There was code all over the place checking that flag.  Then the
business decided that to be (in?)active, not only did the flag have to
be set but some other criteria needed to be met...

Would have loved to simply make a change to the ITEM_isActive()
procedure instead of finding every line of code that had IF ITMACT =
'Y'

Having your own procedures that simply mimic RPG RLA operations is
pointless...the only benefit it provides, being able to replace RPG
RLA with SQL is usually a bad idea since SQL isn't conductive to
record at a time operations (as you've found out).  The other
"benefit" often branded about, "when it comes time to implement a file
change, having that file in one location...." is oftentimes broken as
the data structures passed back and forth are tied the file.  Besides,
you can easily accomplish the goal of minimizing re-compiles by simply
enforcing the rule that all file access is done through a logical with
an explicit field list.  Now you can add fields to your hearts content
and not have to recompile anything.

Finally a word about your SQL example...using a cursor to fetch a
single row, ie. CHAIN, is not the right way to do it.  Instead, you
should be using a SELECT INTO.   However, even SELECT INTO isn't going
to be quite as fast as CHAIN.

Remember my motto, if you're using a cursor, you probably shouldn't
be.  :)  Yes, there are places where you have to use a cursor, loading
a display subfile or printing a report...but otherwise look for a non
cursor approach.

Charles


On Wed, Apr 4, 2012 at 3:29 PM, Kurt Anderson
<kurt.anderson@xxxxxxxxxxxxxx> wrote:

First off, we don't encapsulate all of our files.  Only the ones that have business logic directly associated with the file.
For example:
We have a file with records with effective dates associated with them.  We also have some clients who apply grace periods to their effective dates (that we need to interpret and apply on the fly if a record wasn't found w/o the grace period).  Without this service program, this file would be used in over a hundred programs.  Instead of having every program that needs to use this file have to go through all the gyrations of looking for the effective record, it's all handled in the service program.  I also call this service program a business unit.    The service program is set up so all the caller has to do is code the statement "line = getEffectiveLine( date: otherinfo );  "

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.