|
Here's the section that confuses me. From V7R1 ILE Concepts:
<quote>
_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
ended.
An application may return to a call stack entry (see "Call Stack" on
page 91) associated with another activation group in the following
ways:
≥ 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.
</quote>
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.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/ilec/sc415606.pdf p28.
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
answer.
The /new/ activation is reclaimed upon return irrespective of *INLR:
http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/topic/com.ibm.etools.iseries.pgmgd.doc/c0925076156.htm
"...
_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.
* ...
..."
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.