Gerald,
I think this could be related to that message you posted recently
(quoted below), about "activation groups"...
If you are compiling ILE programs (either CLLE or RPGLE) with
ACTGRP(*CALLER) and somehow getting them to run in the *DFTACTGRP, that
could easily be a big part of your problems. ILE programs were never
intended to run in the *DFTACTGRP, unless you specifically compile them
with DFTACTGRP(*YES). Otherwise, even if you issue RCLRSC, that will
not be able to "reclaim" the resources of those ILE *PGMs.
_D__iagnosis
_You can use the DSPJOB command to display your own job, or another
user's job ... From the DSPJOB display menu, you can use option 12.
Display locks, and on the next screen, press F10=Display job record
locks to see if there are still records "locked", and from the main
DSPJOB menu, use option 14. Display open files, if active to see what
files, if any, are left open. Also, you can use option 11. Display call
stack, if active and on the display of the call stack, press
F11=Display activation group to see what activation group(s) programs
are running in. (You need to look at this option 11 while a user is
"deep down" in the application, and not after they have returned to
the main menu, to see the programs on the stack and their activation
groups.)
_Possible remediation steps:
_As a "next step" for any "top level" programs, (those called
directly from a "menu"), compile them with ACTGRP(*NEW) and that way, a
new activation group gets created automatically whenever they are
called, and any programs called by that "top level" program will run in
the same AG, so long as they are all compiled with
ACTGRP(*CALLER)... then, when the user returns from that "top level"
program to the "menu" the *NEW AG is automatically destroyed and
"cleaned up" -- all files opened in that AG are closed, record locks
released, etc.
If you still have some parts of the applications that are "OPM" and so
must run in the *DFTACTGRP, you can still do that -- just add a "layer"
or "jacket" -- a little OPM CLP program as the "top level" program that
gets called from the menu(s), and it then CALLs the actual OPM program
-- when that program eventually returns to this CLP program, the CL
program issues: RCLRSC LVL(*) to "clean up" any resources for any
OPM programs below this call level.
Any questions?
Hope t hat helps,
Mark S. Waterbury
> On 6/12/2017 4:25 PM, Gerald Magnuson wrote:
I believe I am having troubles with records remaining locked, when the user
gets back to the menu, but I can't find the program(s) that is causing
it.....
Is there a api for me to use, when the user get's back to the menu, to see
if they have any records locked?
the old menu system, was not ILE, and would issue a RCLRSC after it
returned from running an application..... I don't know if that did
anything or not?
> On 6/9/2017 4:34 PM, Gerald Magnuson wrote:
I have noticed that I am doing all kinds of "bad" things in respect to
activation groups...
I don't know where to start, other than maybe changing the command defaults
on CRTBNDCL
to DFTACTGRP(*NO) ACTGRP('<our_named_actgrp>')
we are kinda getting into the habit of compiling our RPGLE programs as
ACTGRP(*CALLER).
But since most of our CL and CLLE is set to *DFTACTGRP, most of our RPGLE
is running there as well....
we don't have /copy on our H specs, or any other real helps in place for
this....
what have others done to help with getting programs created with the
correct activation group settings?
midrange.com
