David FOXWELL wrote:
[Simon]
If a
procedure is using the activation group to retain state (a
common, intended, and desirable use of activation groups) you
will have a, possibly unfavourable, learning experience.
[David]
That looks very interesting. Anyone have an example of retaining state? What is being retained exactly? Would that be the way to go to store variables that one wanted to use globally to all activation groups?
The entire purpose for activation groups is to provide a more granular
environment than 'the job.' Before ILE, 'the job' was how we separated
one set of tasks from another. That is, if 2 jobs each call PGMA, job 1
does not share anything with job 2. For instance, if job 1 does a CHAIN
to CUSTMAST, job 2 does not get positioned to that same record.
This is a very simplistic explanation, but the general idea is that you
can now isolate programs within a job; by activation group. This
isolation aspect is a bit confused by the sharing aspect of SHARE(*YES)
on file opens, and RETURN without LR that some applications use.
Simon's phrase 'retain state' reflects the other aspect of activation
groups: they don't go away during the life of a job unless you tell them
to.
AG A
PGMA
CHAIN record 42 in CUSTMAST
CALL PGMB
AG B
PGMB
CHAIN record 77 in CUSTMAST
RETURN
// AG A and AG B are still both active and each
// one hold a cursor pointing to their separate
// records in CUSTMAST
AG A
PGMA
EXFMT DSPCUST
// shows record 42
CALL PGMC // AG C or whatever
CALL PGMD // AG A or whatever
CALL PGMB
AG B
PGMB
EXFMT DSPCUST
// shows record 77
// each time you call a program in AG B, the
// file cursors, variables, etc. are still there
// waiting to be used.
The best reference for this is the ILE Concepts manual.
--buck
As an Amazon Associate we earn from qualifying purchases.