RE: Why do procedures require DFTACTGRP(*NO)?

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Dan wrote:
>So far, I haven't seen the answer to the question
>"Why do procedures require DFTACTGRP(*NO)?",
>other than because it just does, that's why.

I think that's the reason.

>Our use of modules:  We CRTRPGMOD several source
>members, then CRTPGM; the standard is a "primary"
>module calls the other modules.

OK, so you're using CALLB to invoke the code in the other modules, right?
The step from there to CALLP is pretty easy.

>I know AGs require much more study and practice to truly
>understand them than I currently have time for...

I can't say anything about the time commitment other than my own experience.
I spent an hour or so with the Redbook and another hour or so with the ILE
Concepts before settling down to using a single named AG.  I get away with
that because:
a) I am the only ILE developer so far
b) I do not 'own' all the other code and need to interoperate with OPM
c) My stuff is heavily related to communications and doesn't interact
   with the database much.  (I have internal APIs for the database stuff.)

The consensus of this group is to use the *NEW/*CALLER model.  That is, your
menu programs use AG(*NEW) and everything else uses *CALLER.  So:

MAINMENU - CL
  01 - P/R: call PRMENU
  02 - A/R: call ARMENU
  03 - G/L: call GLMENU

Let's say that A/R and G/L call a common inquiry program: ARINQ.  Here's an
abbreviated list of menu options:

ARMENU
  01 - ARINQ
  02 - ARAPPLY
GLMENU
  01 - ARINQ
  02 - GLINQ

Let's follow the flow of a user doing an A/R inquiry, switching to the G/L
menu and performing a different A/R inquiry:

MAINMENU *DAG
  ARMENU 5F8A9B05 (system generated AG name)
    ARINQ 5F8A9B05 (inherited)
    F3 back to MAINMENU - LR on, AG destroyed
  GLMENU 6A3E768F (system generated)
    ARINQ 6A3E768F (inherited)
    F3 back to MAINMENU - LR on, AG destroyed

It allows for intermingling OPM and ILE as long as your overrides are issued
in OPM.  If you wanted to, you could have a single program on the system
that serves as your initial program, compiled as AG(*NEW) and every other
program AG(*CALLER).

I would argue that the very worst AG scenario you could get into is having a
service program run in the DAG accidentally by a series of *CALLER programs:
MAINMENU *DAG
  ARMENU *CALLER [DAG by inheritance]
    ARINQ *CALLER [DAG by inheritance]
      ARSRVPGM *CALLER [DAG by inheritance]
Any other scheme, including one single AG name for all programs is better
than this.

If I were doing it all over, I would try to think more globally and use the
*NEW/*CALLER model, although I have to confess that I don't see how I can
readily convert a few programs in the middle of a job stream this way.  I
convert programs as I touch them for maintenance, rather than en masse...
  --buck