Why do procedures require DFTACTGRP(*NO)?

 >>  Before I go any further, I should explain that we use RPG modules
extensively here and it has greatly simplified some complex stuff they do
here.

We could go into lengthy debates (and probably will) but in many ways the
simplest and best answer is the one you actually provided!!  Since the shop
uses modules, you must be compiling with CRTRPGMOD - CRTRPGMOD is implicitly
specifying DFTACTGRP(*NO).  That is the simplest answer you can give him -
everyone is already doing it!

Note that DFTACTGRP(*NO) do _not_ mean that the program cannot run in the
default AG (which is why it is a truly stupid name for the parameter) - it
simply means "This program will not behave like an old RPG III program" - a
better name for the parm would have been "Compatibility Mode" which is a
true reflection of what it really means.

Why subprocs not subroutines?  Because one takes parms, returns values,
isolates variables and can be read as English - and the other is a
subroutine <grin>

As to performance of subprocedures vs. subroutines, in practice it can be a
wash.  Because subprocs take parms, you don't have to move large blobs of
data into the fields expected by the subroutine.  That can more than
compensate for the small overhead.  Even if the overhead was huge I'd still
want my programmers to justify why they _didn't_  use a subprocedure rather
than the other way round.

Jon Paris
Partner400