Re: Service programs

Booth:

Reasons to use a *PGM:
===================

1. it is to be invoked from a command-line, e.g. via a COMMAND
interface, or from a menu.
2. it will be submitted to run as a batch job, to:
* generate a report
* perform an end-of-day consolidation process (like in banking)
* perform some kind of "merge/purge" processing
* etc.
3. it will be called from some "client/server" interface that expects
to CALL a *PGM

Reasons to use a *SRVPGM:
======================

1. a service program typically contains a number of "related"
procedures to perform various "services" for a given "entity" type,
for example:

* for a "banking application" you might have a service program
such as:
o LOANS that contains procedures named:
+ createLoan
+ updateLoan
+ applyLoanPayment
+ closeOutLoan
+ cancelLoan
+ etc.
* for a personnel system, you might have service programs like:
o EMPLOYEES
+ hireNewEmployee
+ terminateEmployee
+ updateEmployeeSalary
+ etc.

The idea is, it lets write more modular code, with separate source and objects for each unique "object type" (or entity type).Then, writing your "main line" of your applications becomes mainly just a sequence of procedure calls to these various procedures to carry out actions against the various objects they represent.

Of course, you can imagine how you could just have a LOANS table and an EMPLOYEES table, etc.,butt he idea is to "encapsulate" all of the "business rules" -- for example,you cannot update the salary of an employee who has been terminated, etc., and so then, the "main line" code does not have to worry about or deal with all of the "business rules"... And, there may in fact be a LOANS table, or an EMPLOYEES table, but access to it is "encapsulated" using the procedures provided by the corresponding "service program" (some call these "I/O modules").

From a software maintenance point of view, changes to "company policy" (for example) that may affect some of the "business rules" for an "employee" should require making changes in just one place, in the relevant procedures within that one EMPLOYEES service program.

"Modular" programming evolved from the old "monolithic" style of programming, where everything was mixed together in one large program, and evolved into "object-oriented" programming styles, with newer OO languages sporting even more OO features to better support that style of programming. But, you can do "object-oriented" programming using just these basic design tools that ILE provides, especially *SRVPGMs to represent the objects or entities and using procedures to implement the "methods" that act on those entities (to use OO terminology).

It's called "object oriented" because typically each "module" represents one "object" in the "real world" or in the application's "problem domain".

Hope that helps,
/
/ Mark S. Waterbury

> On 5/15/2017 3:24 PM, Booth Martin wrote:

Why would one use a service program instead of a stand-alone program? and the opposite?

For the sake of discussion, lets use a FAQ program that is for the F1 key in programs and is system wide. Its the same everywhere - the only change being the FAQ data file which is determined by the library list. It displays FAQs and can be edited to add, delete, and update questions. Its an actual application I use, as a standalone program.

So, I see Service Programs mentioned and think I should change how I do it. Then I look at the process and scratch my head. Why would I make the change? What is the benefit? The more I read about it, the faster I scratch.