RE: File encapsulation

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, November 25, 2005 1:22 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: File encapsulation


> Our group is thinking about encapsulating file access in service
> programs. Concerns have been voiced about the impact on performance
such
> a move would have.

One of the goals is to isolate the calling programs from the file. So,
the model outlined below is how we plan to proceed. You're point about
performance is what prompted the question in the first place. We do plan
on conducting performance tests of our own, but I was hoping to get some
feed back from the list on that.

Tony
Alliance Software Development

However, what if you do the following?

      P custmas_chain   B
      D custmas_chain   PI             1N
      D   custno                       4P 0 value
       /free
           chain(e) custno CUSTMAS;
           return %found;
       /end-free
      P                 E

      P custmas_getName B
      D custmas_getName PI            30A
       /free
          return custName;
       /end-free
      P                 E

      P custmas_getAddr B
      D custmas_getAddr PI            30A
       /free
          return custAddr;
       /end-free
      P                 E

      P custmas_getCity B
      D custmas_getCity PI            15A
       /free
          return custCity;
       /end-free
      P                 E

      ...  with more "get" routines, one for each field in CUSTMAS ...

This code is better than the first code sample because it it helps keep 
the database separate from the calling routine.  The program that calls 
this doesn't need to know the exact sizes of the fields, since they're 
returned by value and the system can do conversions.  The program that 
calls it doesn't need to know the exact data types for the same reason.
It 
doesn't need to know the from & to positions of the record, etc. So it 
really helps keep the database logic separate.

However, on the other hand, it also has a bigger impact on performance. 
You no longer are calling only one subprocedure when you load a record, 
you're now calling many of them, one for each field, and that'll hurt 
things.  And, again, what have you gained?  Is what you've gained enough

that it makes sense to implement things this way?

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.