Re: ServicePrograms VS normal Programs

Hello Igor,

> I read some articles abouth service programs and now I am wondering is it
> better to make a service program with collection of subprocedures that
> will be repeatedly called (with callP) from other programs, or is it
> better to have every subprocedure as one rpg program (and call it with
> call).

Depends on what you mean by "better." I generally put anything that's
intended to be reusable in a service program. Everything else goes in the
main program object, unless the main program object is getting too large,
in which case I break it into modules.


> What is diference in performance?

Calling an internal routine is faster than calling one in a service
program -- but please don't make decisions based on this.

There may be an occasional routine (for example, cryptography routines)
where you need to optimize it to make it as fast as possible -- but this
is rare, especially in business programming.

Putting all of your routines in the same program to improve performance is
like storing all of your data in variables in the program to improve
performance. (i.e. eliminating files completely)  Sure, it makes things
faster, but it makes programmers less productive and makes maintenance
MUCH harder. The millisecond that you gain in performance will never
outweigh the days and days of extra maintenance work.

> What is exactly happening when an program calls subprocedure from
> service program with callP and what is happening when program calls
> another program with call and parametar list.

At a technical level?  I'm not sure that I know the difference. All I can
tell you is that service program calls are much faster.

> I am asking this because I am Java programer and fresh RPG programer and
> most of RPG things I learned from IBM's student books and Sourcers Guide,
> but my collegues (who code in RPG all their life) have totaly diferent
> aproach that doesn't meet any ruels (described in RedBook) of advanced and
> modern coding.

Unfortunately, this is the sad state of RPG programming today. RPG
programmers refuse to learn new techniques, refuse to modernize their
code, refuse to modernize their user interfaces.

This ultimately leads to a negative perception among users and management,
resulting in the system to lose market share -- despite it's technical
superiority.