× 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.



I started writing this giant note about activation groups, but then realised
that having an ongoing peer review would be better.  So here's my opinion on
AGs.

Multiple AGs are intended for complex environments.  A programmer moving
gradually from S/38 code into ILE doesn't need to be uptight about what AG
to run in.  Run in QILE.  NOTE: This is a controversial opinion.  I'll try
to substantiate it below.

NAG - Named activation group
DAG - Default activation group
Scope - How long a variable/program activation/OVRxxx lives

NAGs are not system objects.  They are like QTEMP - there's one for each
job.  I keep it straight by thinking of a NAG as a subdivision of a job, so
my QILE runs in my job: 123456/BUCK/QPADEV0001/QILE and your QILE runs in
your job: 1234567/QPGMR/QPADEV0002/QILE.  They do not know about each other,
any more than job QPADEV0001 knows about QPADEV0002.

Named AG's come in to play for two things: Shared file opens (override
scoping) and program activations.

Override scoping.  An override issued in the DAG carries forward into all
other AGs.  An override issued in a NAG exists only in that NAG for that
job.  This behaviour is fine for the situation where an OPN CL program does
some overrides, then calls a mix of ILE and OPM programs, where the ILE
programs run in a NAG.  If you use shared ODPs, post a to this thread to
have the behaviour explained in light of AG scoping.  If you want to learn
about shared ODPs, please open a new thread.

Program activations.  A program in a NAG stays active until the AG is
destroyed.  This is important if you do RETURN with LR off.  If you use
RETURN with LR off, post a note to this thread to have this behaviour
explained in light of AG-based activations.  If you want to learn about
RETURN with LR off, please start a new thread.

So, my "baby step" strategy is this: DFTACTGRP(*NO) ACTGRP('QILE') under
these conditions:
a) No shared ODP
b) Overrides issued by OPM
c) LR always on at program end

When the inevitable response comes talking about performance, carefully
weigh this important fact: your current environment has no shared ODP and LR
is always on.  That's the worse-case performance scenario.  The easiest to
program, but worst performing.  A single named AG per job is not going to
make that noticeably better or worse.

Here we go!

  --buck


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.