RE: diff btw Procedures and Routines

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

>I've been 5 years trying to get this straight
>and am still confused.  Lets say I have a
>utility program that is a pop-up calendar.
>The parm is a date.
>  Should this be a program or a procedure?

That's easy Booth!  Yes!  :-)

Generically, the whole reason for procedures/service programs is speed.
Calling a subprocedure is much quicker than calling a program.  If you are
processing a million orders a day you want all the help you can get.  If
this pop-up gets called a few hundred times a day you probably don't notice
the workload.

If you must invoke the popup from OPM you'll need to either leave the pop-up
as a program OR write an ILE program to callp the pop-up procedure from it's
service program.  Which adds a bit more overhead to the OPM programs that
need it.

Finally, OPM programs can be made to respond pretty quickly if you don't set
LR on.  My typical routine looks like this:

Main
eval done = 'N'
call pop-up
parm date
parm done
  Pop-up
  *entry plist
         parm date
         parm done
  if done = 'Y'
    seton LR
    return
  endif
  exfmt...
  return
do other Main stuff
seton LR
eval done = 'Y'
call pop-up
parm date
parm done

With a scenario like this, Pop-up will open files only once; initialise
variables only once.  Subsequent CALLs to it will be very fast indeed.
Sharing open data paths was the next logical step.  This is how we made S/38
RPG programs run very quickly.

Finally (you thought I'd never shut up didn't you?!), subprocedures can't be
explicitly put into an activation group but programs can.  This makes no
difference to most people but for those few who care, this means a lot.  If
you have some desperate need to run Pop-up in a separate AG AND it's a
procedure, you will have to put him in his own service program which in turn
goes into his own AG.  This is not likely unless you already have a complex
environment with OPM programs staying open and shared ODPs, but if you need
it, you need it bad!

In short, if you are satisfied with the performance of your *PGM, stay with
it.  If you will be invoking it dozens of times per transaction and want to
improve performance, consider a subprocedure/service program combo.
  --buck