RE: File encapsulation -- RPG400-L

This is a good starting point for the discussion.

> What did you have to do to get to the above statement? A chain? A> read? How were those sub procedures written that have the chain and> read in them?


Or an SQL statement. What ever it takes to get the data you want. The
internals are important only during the design and implementation. The
object is to make the end-product reliable and easy to use. Plus, it's
not necessary to think of everything upfront. There's no need to code
for a data access method that's never used. If someone decides to use it
in the future, they just update the service program.

The problem with this is that there's no way the service program can knowof how a caller is going to use it, unless business logic is specified inthe design of the module.

Some programs will want to read some logical files. Others will want toread the PF in arrival sequence for best performance. Some will want touse blocking to speed up the process. Some will want each record lockedso they can perform an update. Some will want an SQL query that joinsfiles together, filters on certain criteria, and orders the data bycertain criteria.

Since there's no way that your service program can possibly know how it'llbe used, what happens? You end up writing routines like


     invoice_open_with_blocking()
     invoice_open_for_update()
     invoice_chain()
     invoice_read()
     invoice_open_sql_query()
     invoice_read_sql_cursor()

Now the calling application needs to know whether it wants blocking ornot. It needs to know whether it wants the file open for update. It needsto know whether it wants to use SQL.

In other words, the caller is no longer completely separate from thedatabase logic! It needs to understand something about the underlyingimplementation -- and that's exactly the problem with this type ofthinking.

Instead, you need to look at it as a business problem, not a databaseoperations. You need business logic to make that happen.


Your routines should be:

   invoice_load();
   invoice_change();
   invoice_getAllUnpaid();
   invoice_findByCustomer();
   invoice_findByTotal();

That way, you can completely separate the implementation of the routine.The caller doesn't need to know whether a database is used, or whetherit's a stream file, XML file, web service, etc. All it knows is that itwants to find the unpaid invoices -- it doesn't care how the fileencapsulation routine goes about doing that.

That's the point I've been trying to make (and I'm not sure I'vesucceeded) in this thread.

If the need for more of these functions comes along later, you'reabsolutely right, you can write the additional routines then and add themon -- no need to try to figure them all out in advance, or code thingsthat may never be used.