Hi Patrik,
as far as I understand, activation groups are kind of a shared memory area for multiple programs to be run in. Correct?
This is not how I understand activation groups to be. I'm not sure they actually exist as a physical thing, I rather think they are more of a conceptual idea whereby you effectively give a label name to resources that your programs use, thus allowing you to better scope and reclaim these resources using the label name.
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.
Activation groups give you finer control over when your resources are given back to the system, rather than that having to be at program level or job level. The system I work on tends to use an activation group for each area of the system accessed via the menu, and when the user returns to the main menu the activation group for that area is reclaimed For example, if you go into order entry, the system is going to open files and load service programs and programs related to order entry [with, for example ACTGRP(ORDENT)], and while the user is navigating around within the order entry part of the system these files and programs should stay open and resident. However, when the user goes back to the main menu, the activation group ORDENT can be reclaimed, thus returning all of the resources scoped to order entry back to the system. In the old days you might have had to manage this by calling programs specifically with a set-on LR option when you were done with them - not that most people bothered IME.
Activation groups also allow you to scope your resources better so, for example, two different copies of the same program running in the same job don't interfere with each other if they run under different activation groups and overrides can also be scoped to activation groups, thus giving you finer control over where these overrides are applied.
Tim.
________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Patrik Schindler <poc@xxxxxxxxxx>
Sent: 17 February 2020 23:09
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Activation Groups, yesterday and now?
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!
:wq! PoC
PGP-Key: DDD3 4ABF 6413 38DE -
https://www.pocnet.net/poc-key.asc
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
