From: Birgitta Hauser
An colleague argues having a lot of service programs is not good, he
insistsin having a single service program with all modules for the whole
application ...
One of my colleagues offers the same advise, and goes so far as to say that IBM recommends it. And I must admit that after the first activation of his programs, subsequent activations from different jobs seem to be quick. He also contends that memory is managed better with large service programs.
But I've never followed that advise. 99% of my programs and service programs are single module entities, divided by subject area. Even my IFS related procedures are divided into two (2) service programs - one for files, another other for directories.
I've accumulated quite a few utility service programs, which are activated by most applications.
I also follow a particular design pattern for browser-based database maintenance applications, which normally consists of one program, and 2-3 service programs per database table - the *PGM does little more than load HTML templates into memory, and dispatch browser requests to particular "action handlers". One service program performs browser request / response logic & I/O, while another performs data validation, database logic, & DB I/O, which has turned out to be easy to maintain.
My rationale for doing things this way was mostly just to keep things organized and streamline the build process - following my own instincts, rather than what a colleague might recommend.
Nathan.
midrange.com
