The *NEW activation is also a new _hard_ Control Boundary. That is
because the *NEW activation is always an "ILE call stack entry for which
the immediately preceding call stack entry is associated with a
different activation group"; i.e. the system names the new temporary
activation with a unique name from any other existing in the job [and
thus also the stack]:
_i Non-Default Activation Group Deletion i_
That control boundary is a hard boundary because there can not be any
earlier call stack entries that exist for the same activation group,
because any prior invocations would have effected a *NEW [temporary]
activation; i.e. each is unique.
No matter by what means the call stack entry leaves the stack, the
/new/ [temporary] activation should be implicitly reclaimed. As noted
in the referenced doc snippet, "Whether the activation group is deleted
*depends on the type of activation group* and the method in which the
application ended." The *NEW activation is always deleted\reclaimed
whenever the stack entry that initiated that temporary activation leaves
the stack; irrespective the means for that stack entry going away, be it
per an exception, an end, a return, or etc.. Later in the same doc
reference in the earlier quoted reply, i.e. the ILE Concepts, is the
"Figure 18. Leaving User-Named and System-Named Activation Groups" that
shows how irrespective the type of /return/ the *NEW activation will
reach the phase entitled "Always Delete" for the system-named
Note also in the third sentence in the following doc link, the lack
of any qualifiers [about how the so-called /return/ is effected] for the
statement about such an activation:
IBM i 7.1 Information Center -> Programming -> Programming languages ->
RPG -> ILE RPG Programmer's Guide -> Creating and Running an ILE RPG
Application -> Running a Program -> Managing Activation Groups
_i Deleting an Activation Group i_
"When an activation group is deleted, its resources are reclaimed. The
resources include static storage and open files. A *NEW activation group
is deleted when the program it is associated with returns to its caller.
Named activation groups (such as QILE) are persistent activation groups
in that they are not deleted unless explicitly deleted or unless the job
ends. The storage associated with programs running in named activation
groups is not released until these activation groups are deleted.
An ILE RPG program created DFTACTGRP(*YES) will have its storage
released when it ends with LR on or abnormally.
The storage associated with ILE programs running in the default
activation group via *CALLER is not released until you sign off (for an
interactive job) or until the job ends (for a batch job).
On 29 Jul 2013 14:06, Dan Kimmel wrote:
Here's the section that confuses me. From V7R1 ILE Concepts:
_i Non-Default Activation Group Deletion i_
Activation groups require resources to be created within a job.
Processing time may be saved if an activation group can be reused by
an application. ILE provides several options to allow you to return
from an invocation without ending or deleting the associated
activation group. Whether the activation group is deleted depends on
the type of activation group and the method in which the application
An application may return to a call stack entry (see "Call Stack" on
page 91) associated with another activation group in the following
≥ HLL end verbs
For example, STOP RUN in COBOL or exit() in C.
≥ Call to API CEETREC
≥ Unhandled exceptions
Unhandled exceptions can be moved by the system to a call stack
entry in another activation group.
≥ Language-specific HLL return statements
For example, a return statement in C, an EXIT PROGRAM statement in
COBOL, or a RETURN statement in RPG.
≥ Skip operations
For example, sending an exception message or branching to a call
stack entry that is not associated with your activation group.
You can delete an activation group from your application by using HLL
end verbs or by calling API CEETREC. An unhandled exception can also
cause your activation group to be deleted. These operations will
always delete your activation group, provided the nearest control
boundary is the oldest call stack entry associated with the
activation group (sometimes called a hard control boundary). If the
nearest control boundary is not the oldest call stack entry
(sometimes called a soft control boundary), control passes to the
call stack entry prior to the control boundary. However, the
activation group is not deleted.
RPG using "return" is NOT an HLL end verb. This section above
implies that a program that returns control to another program in
another activation group without using an HLL end verb and without an
unhandled exception will not delete the activation group.
CRPence on Monday, July 29, 2013 3:14 PM wrote:
On 29 Jul 2013 11:45, Dan Kimmel wrote:
There's some vagueness in the ILE spec that I'd like to have
others comment on that's brought up by your post below.
Program A, running in system-assigned activation group 32 calls
program B for the first time and program B was compiled CRTPGM
ACTGRP(*NEW), the system will create a new activation group in
your job and call it, say, 33 and run program B in that
activation group. This much is clear from the spec.
If program B returns without setting on LR and program A or
another program operating in activation group 32 calls program B
again, the system will continue to use the copy of program B in
activation group 33. This is NOT clear in the ILE programmers
guide, but I believe it to be the case. <<SNIP>>
But I'm getting old and don't remember for sure and went to the
ILE programmer's guide to confirm and couldn't find a definitive
The /new/ activation is reclaimed upon return irrespective of *INLR:
_i Returning without Ending i_
If you call a main procedure and it returns without ending, when
you call the procedure again, all fields, indicators, and files in
the procedure will hold the same values they did when you left the
procedure. However, there are three exceptions:
* This is not true if the program is running in a *NEW
activation group, since the activation group is deleted when the
program returns. In that case, the next time you call your program
will be the same as if you had ended with LR on.