RE: Subprocedures and files (was: Procedures are FUN!)

> From: Buck Calabro
>
> Please remember that I do not use CALLB, and have literally never even
> considered doing a CALLB against the PEP of a RPG procedure.  I
> always call
> the procedure directly.
>
> I thought I read that this was to be a mixed environment: OPM
> programs doing
> a dynamic CALL to PROC1 and ILE programs directly calling the getrec()
> function.  If this is the case, where does the CALLB to PROC1 fit in?  Why
> not make PROC1 a program and CALL it?

This is part of a staged conversion from RPG III to ILE RPG IV:

1. Convert CALLs to CALLBs.  Compile the called programs as modules, and
bind them.  This works wonderfully.  Rather than having to deliver a couple
of dozen programs, I can deliver a single executable.

2. Replace the CALLBs with CALLPs.  This involves separating the code from
the called program into a callable procedure.  However, if a program is used
extensively, changing the procedure gradually is a little easier than doing
a wholesale change.

3. Separate out common modules into service programs.  Once done, I'll have
a "proper" ILE environment, with subordinate modules bound to their drivers,
and common modules in service programs.

Step two is the one that caused me to attempt the technique I've outlined.
After step one, all programs use CALLB.  By separating the module into an
exported procedure but leaving the mainline, I can gradually modify the
calling programs to use CALLP rather than CALLB, but I don't have to do it
all in one go, making regression testing easier.

> I would 'solve' it by CRTRPGMOD and CRTBNDRPG for
> PROC1 and doing a CALL PROC1 instead of CALLB PROC1, but that may
> not fly in
> your environment if you have issues with sharing the ODP.

The point of the exercise is to remove the CALLs.  At the end of the day, I
want to have nothing but direct procedure calls in my environment.  I
thought I had stumbled upon a "clever" way of easing that transition, but as
is often the case, clever techniques have a tendency to bite.

Separating the business logic into a second module and then using a stub for
the legacy programs is a feasible workaround, just not as elegant as I had
hoped for.

Joe