RE: external subprocedures setting on LR: performance impact?

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Dan wrote:

>The thing that struck me is that each of these 
>called procedures sets on LR each time it is 
>called.  These procedures all have several
>files defined, and this means that they are 
>opened and closed each time they are called, right?

Once more, foot into my mouth!  For what it's worth, in my opinion, using
subprocedures this way is not a good way to design an application.  I
believe the intended use of subprocedures is to do ONE SIMPLE thing, and
that it should know NOTHING about global variables.  Some think me Utopian,
but why make a subprocedure if the guts are basically a complete program?  I
mean, why not just leave it as a program?  

That out of the way, the file behaviour is dependent on whether the bound
procedures are in the same AG or a different one, or in *NEW.  In ILE, the
activation group takes precedence over the program, sort of.  The ILE
Concepts has more on this, and better than I can explain.

>Is this a no-brainer?  If I remove the LR from being 
>set on, and just issue a Return, won't the files stay 
>open until the job ends?  (This is a batch job.  
>And there are no USROPNs on the files.)

Depends on the AG.

>The only things I think I need to watch for 
>is to determine whether any *INZSR stuff 
>needs to be moved out so that it runs on 
>each invocation.  And also any working fields 
>that are expected to be in a "cleared" state 
>at the beginning of each invocation, I 
>will need to explicitly clear those.

Sounds right based on what I can tell.  Remember that an activation group is
supposed to live a long time, and keep things going so to speak, so that
procs don't have to initialise the world every time they're called.  That's
some of the time savings.  I would guess that shared file opens and no LR
would help.
  --buck