having a look to ILE RPG (it would look very diffrent for ILE C++) from the
perspective of the 21st century:
- all object oriented programming languages programmers have full controll
of creating objects and their lifecycle. You could create objects whenever
you would need one, new objects are proper initialized, existing objects
could hold statefull information if needed, existing objects could be passed
as parameters to other objects, orphans are destroyed automatically. All
this is controlled at runtime - nothing to do at compiletime.
RPG has none of this (it seems to be a little bit outdated - totally free,
free or not free doesn't make any diffrence here!) The one and only you
could do, happens at compiletime - controlled by ACTGRP.
- named ACTGRP: this is called a Singleton in modern languages:
-- only one instance will exist
-- all statefull information will be hold "forever"
-- ILE will create this automatically, if needed
- ACTGRP(*NEW)
-- from the perspective outside of this object it is absolutely stateless
-- nobody would use this in an OO language
-- nearest to this in Java: the very first programm, containing the main to
start an application
- ACTGRP(*CALLER)
-- closest to an OO Object
-- very limited compared to true OO
-- only one object per (callers) ACTGRP
ACTGRP and Database Connect:
- ACTGRP is similar to a local database connect (one to one relation) (=>
commit scope)
- could be circumvented by CLI or severmode (nobody is doing!)
- performance is no argument
-- access plans are cached automatically in diffrent levels
-- if temporary indexes are a problem ibm should solve this at database
level (like oracle e.g.)
-- most of this could be done by creating the needed indexes
Job is comparable to a running JVM
In most scenarios my recommendations are rather simple:
- true singletons: ACTGRP(NORECLAIM)
- all SRVPGMs and Subprogramms (e.g. SQL DAOs) ACTGRP(*CALLER)
- entry programm at menu level only (ACTGRP(*NEW)
-- all other programms ACTGRP(ProgrammName)
D*B
<Patrik>
Hello folks,
as far as I understand, activation groups are kind of a shared memory area
for multiple programs to be run in. Correct?
Years ago, I stumbled across a file pointer not jumping back to *LOVAL,
because the default compile option of ILE RPG (at least with V4) was
DFTACTGRP(*YES). Obviously, certain attributes of programs will be retained
between runs. That's when I started to always use DFTACTGRP(*NO)
ACTGRP(*NEW) when compiling.
I'm very used to the concept in "common" operating systems that if you end a
program, used resources are claimed back by the OS and said compiler options
force this behaviour.
Now I wonder, what are activation groups actually good for? Or, have been
good for 30 years ago? What's the benefit in putting a bunch of programs
into the same (named, or default) activation group today? Is it "just" for
omitting the overhead for repeated program activation between runs? Even on
my ancient 150, programs are starting blazingly fast.
I have a dim idea what "activation" does. AFAIK it's tied to the SLS
peculiarities. An unactivated program is just an ordinary object at some
address in the vast memory space. An activated program has associated
certain resources, so it is actually able to run and do stuff. (At least
that's what I understand from reading
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/ilec/ileacpa.htm)
Correct?
I've been reading through some resources at the internet but there was none
which gave clear answers to my above questionary. Most of them also are a
bit dated.
Thanks!
</Patrik>
midrange.com
