Re: File Encapsulation Quandary

This had me wondering how other shops handle file
encapsulation.

The question is what scope should a service program have?  How much functionality should you put into it? That's the real art and design of programming. And it depends on the use case.

We will often create service programs with just 2 procedures, one to retrieve a record by primary key, and another to return a "description" of that entity. For example, one procedure to retrieve a "student record", and another to return "student name", because "student name" appears on many screens and reports. We have a lot of service programs that retrieve data from specific "entities". An "input only" use case, if you will. Aside from that, I've never seen the point of writing service programs that exported a set of procedures that were simply substitutes for comparable RPG I/O op codes.


When we write service programs that include write, update, and delete op codes, we will implement data validation, business rules, user messages, other behaviors, or interfaces that are relevant to the context at hand. The context at hand is generally a DB maintenance program, however the same DB I/O service program could be bound to one program that exposes a desktop UI, and another that exposes a cell-phone UI.

Although we have uses cases for encapsulating single file I/O in service programs, we also have use cases for programs and procedures that incorporate any number of "F" specs, so I wouldn't restrict programmers in that regard. We write a lot of programs and service programs that perform database I/O from any number of files. "File encapsulation" doesn't necessarily mean just 1 or 2 files per module.


We generally use RLA for single record I/O, and we generally use SQL for set oriented I/O. Regarding the question of performance and efficiency of RLA vs. SQL, what most people don't realize is that SQL allocates large blocks of heap storage and often builds huge networks of records in memory in order to perform well. Most programs that use only RLA don't allocate any heap space, at all. SQL may perform well in an individual job, but leads to increased resource utilization, which ultimately may negatively affect overall system performance. Be a good citizen and use RLA when the use case calls for single record I/O.

-Nathan