Re: What's the difference? -- RPG400-L

On Mon, 18 Nov 2002 fkany@averittexpress.com wrote:
>
> I've been trying to figure out the difference between an RPG subprocedure
> and an RPG program.    So far, I don't see much of a difference on how they
> take in data, process the data and send it back.
>

Subprocedures are really more akin to subroutines than they are to
programs.  They're like subroutines with parameters.   Sure, you could
write programs instead of subroutines, but performance would suffer
greatly, and you'd lose the convienience of having the code right inside
the same program where it's easy to reference & keep track of.

The same is true of subprocedures...  they have the advantages of the
program call (well defined interfaces of input/output parameters, local
variables, etc) with all of the speed & convienience advantages of
subroutines.

> Lets say I have a subprocedure that converts an incoming date format to
> another date format. Someone could also write a small program that does
> the same thing.  Why would a programmer choose writing a subprocedure
> over writing a program?  I hope I'm not asking too silly of a question.

It sounds more like you're referring to "modules" instead of
subprocedures... or maybe "service programs."   Subprocedures are parts
of a larger program, like subroutines.   When you put them into a service
program, they can be called from outside the larger program, but they're
still more akin to subroutines than they are to programs.

There are times when it's nice to split source up into smaller chunks to
make it more readable, and more reusable.  But if that's taken TOO far,
you can end up with a maintenance nightmare.  Likewise, putting
everything into one big huge monolithic program is a maintenance
nightmare.   You have to find a happy middle ground.

Having a seperate program for every subroutine would be a maintenance
nightmare.   (and then some!)

Even for every 'generic utility' it would be messy.   You need a way to
group like-minded utilities into one program object where they can be
managed efficiently.  That's what a service program is.   You can have
many utilities in one program object, all callable individually.

Not only that, but in a tight loop over a million database records,
calling a program would be horribly inefficient.  With subprocedures in
a service program, it's nearly the same speed as calling a subroutine.

Subprocedures can also return values, so they can be used in expressions,
which program cannot do.  But, that's a minor gain in comparison to the
other things.

Am I making any sense here, or just rambling?  I find subprocedures in a
service program to be MUCH nicer to use than programs.  But trying to
explain why is REALLY difficult.

Let me ask you this.   Why use a program instead of a subprocedure?  Aside
from the obvious "because I always have" answer, what's the benefit?
Program calls are inefficient, have no way of making sure the interface
hasn't changed, and are difficult to maintain unless you only have a few
of them.  They're limited to 10-character names.  It's difficult to share
"state" data amongst multiple routines.

I guess that it really comes down to is...   subprocedures & service
programs just lead to better code.

But how do I explain it?  Maybe someone else can put it into words, I
really can't.   All I can say is that if you work with subprocedures a lot
and they become the normal way of coding for you, you'll quickly wonder
how you ever lived without them.