× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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>



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.