Re: ILE program with ACTGRP(*CALLER) called from *DFTACTGRP

Hi, Barbara:

I have discovered that the *DFTACTGRP is also "cleaned up" when you run the "Reroute Job" (RRTJOB) command to start a new routing step within an interactive job. (RRTJOB seems to put the default activation group back to a state very much as it appeared at the start of the job.)

For testing and debugging purposes, it can be useful to "purge" whatever was activated into the default activation group, without having to sign-off and sign-on again, and the RRTJOB command seems to do this.

NOTE: I would not suggest using RRTJOB in any "production" application code, as you normally would not want to start a whole new routing step "in the middle of" a running application -- prompt RRTJOB and read the help text or search the Knowledge Center for more information.

I see this in the help text for RRTJOB:

3. If the RRTJOB command is issued in a CL program, all subsequent commands in the CL program are bypassed.

Restrictions:
1. The job must not be a group job, prestart job, batch immediate job, or a batch job in restricted state.

Having multiple routing steps within a job goes back to CPF on System/38, but it seems to be little understood and not very well documented in the modern manuals, and so it seems to be rarely used.

Most interactive and batch jobs have just one routing step, and so, when that routing step ends, the job ends.

I found this explanation of RRTJOB in the System/38 Control Programming Facility Programmers Guide (SC21-7730):

Rerouting initiates a new routing step within the same subsystem.
File overrides are removed, allocated objects except the work
station and job message queues are deallocated, and files are
closed. The library list stays the same, because it is specified at
the job level. The temporary library QTEMP is not deleted, and all
job attributes remain the same.

I am posting my findings in case it may be useful when doing development and you need to replace *PGMs or *SRVPGMs that may have been activated into the DAG, e.g. during testing and debugging. The REPLACE(*YES) parameter on the create commands will move the prior version of a *PGM or *SRVPGM to QRPLOBJ, and it will be renamed to "Q" plus a timestamp, but if it was "active" or "activated" in any activation group, it will still be "active" until you issue RCLACTGRP for ILE activation groups, or issue RRTJOB to "clean up" the DAG' otherwise, your only recourse is to sign-off and sign-on again.

All the best,

Mark S. Waterbury

> On 10/28/2015 7:49 PM, Barbara Morris wrote:

On 10/28/2015 11:37 AM, Jeff Young wrote:

All,
For an ILE program with ACTGRP(*CALLER) called from *DFTACTGRP, what
activation group does it run in?
If the ILE program is RPGLE and ends with *INLR = *On, do all files get
closed and record locks released?

If an RPG program ends with *INLR = *ON, then all files get closed and record locks released, independent of the activation group.

To be more precise, if the program has more than one module, setting on *INLR in the main module would only affect files and record locks in that module. If other modules had files open, they would stay open until the activation group ends.

- If the program is in actgrp *NEW, the actgrp ends when the program ends.
- If the program is in *CALLER called from the command line, the actgrp ends when the job ends.
- Otherwise, for a named activation group, the actgrp ends when it's reclaimed, and also sometimes when a program in the actgrp ends with an unhandled exception.