MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » July 2013

RE: QILE activation group?



fixed

Here's the section that confuses me. From V7R1 ILE Concepts:

<quote>
Non-Default Activation Group Deletion
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:
v HLL end verbs
For example, STOP RUN in COBOL or exit() in C.
v Call to API CEETREC
v Unhandled exceptions
Unhandled exceptions can be moved by the system to a call stack entry in another activation group.
v Language-specific HLL return statements
For example, a return statement in C, an EXIT PROGRAM statement in COBOL, or a RETURN
statement in RPG.
v 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.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, July 29, 2013 3:14 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: QILE activation group?

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.eto
ols.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.
* ...
..."

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.








Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact