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

> From: Jon Paris
>
> I would replace the original CALLs directly with CALLPs Joe.  The
> intermediate step is a waste of time.  The CALLP can call to a
> bound program the same way as CALLB.

I think we approach the concept of procedures a little differently.  The
reason I chose to convert to bound calls was to reduce the number of program
objects with minimal code changes.  Converting CALL to CALLB accomplishes
this.

The conversion from CALL to CALLB makes a lot of sense in my environment,
because it was very easy to do.  Simply replace the CALL opcode with CALLB,
compile the called programs as modules, and bind.  This is much easier than
coding the prototype for each call, especially since - and this is crucial -
the prototypes would all be thrown away.  You may not see the need for this
step, but that's okay.  I did.

So why didn't I prototype my PLISTs?  Why do I say that the prototypes would
be thrown away?  Because the direct conversion of a PLIST to a prototyped
call doesn't take into account the most powerful feature of a procedure: the
return value.  As I'm converting my subprograms to procedures, at least half
are being changed to return values.  This is not possible with a simple
conversion of a PLIST to a prototype.

If your idea of using procedures is simply prototyping your PLISTs, so be
it.  I find that far more fundamental changes occur as I move from PLISTs to
procedures, and that's why I use the staged approach.


> CALLP means "call with prototype" not "call
> procedure" - depending on the keyword EXTPROC or EXTPGM the compiler will
> generate a CALLB or a CALL.  It is one reason why I recommend prototyping
> _all_ program calls - then when you want to bind all you have to do is
> change the proto and recompile all affected sources!!

Because I find a fundamental difference between PLIST linkage and procedure
linkage, this approach won't work for me.  As I pointed out, less than half
of my procedures could even be called using a PLIST.


> As a related thought - why are you ultimately converting to CALLPs to
> subprocs as opposed to returning result sets?  It doesn't seem to
> make a lot of sense.

I'm not sure what a result set has to do with anything.  Are you talking SQL
result sets?  If so, that's completely foreign to my tool.  My procedures do
things like finding user-defined attributes for a program or determining the
change date of a source member - what has that got to do with result sets?

If you're suggesting using result sets as a basic form of inter-program
communication, my reasons against that are far too numerous (not to mention
off-topic) to go into here.

Joe