RE: Subprocedures and files

> From: Jon Paris
>
> No I think we just completely mis-understood one another.  I had assumed
> (incorrectly obviously) that being the little old tool builder
> that you are
> you'd have written a tool to build your protos for you.  Then as they were
> adapted to procs would modify them appropriately.

Okay, I understand.  But since I am doing this in steps, and don't plan to
keep the prototypes for the old PLIST architecture, I didn't see a benefit
to making prototypes I'm not going to keep.  That was purely a pragmatic
decision, nothing to do with "proper" technique.


> As to "result sets" - l simply meant the pieces of data returned by the
> proc.

Again, I understand.  I was confused by the term result set, you were
confused by my inclusive use of the term "CALLP", because I used it to
loosely represent both CALLP and the more functional eval x = proc(y:z).  My
fault; I just don't have a good snappy term for the latter syntax, so I used
CALLP to mean both, assuming you'd understand what I meant.  My bad.


> The point I was trying to make, which seems to have been missed
> completely,
> was that protos have nothing to do with procedures per se - a program call
> can be prototyped, as can a bound call to a "program" module, as can a
> function or procedure.  I just happen to think that adding this level of
> bullet proofing to the call is _always_ worth while.

I think I understood this part at least.  And while it makes perfect sense
when starting from scratch, that doesn't apply to this particular project.
My original code was written in RPG III, converted to RPG IV, and is now
being rearchitected to ILE.  Prototyping the original (and in many cases
soon to be deceased) PLISTs is an extra intermediate step that I decided to
forego.  You may not agree, but it was a pragmatic choice based on my
immediate situation.

Joe