RE: Activation groups for beginners

>For interactive programs, should an AG be
>active for the life of the job, or
>should an AG start and end with a menu
>option (which means, clean up the AG
>when returning to the menu)?

It depends on how your application is architected.
It's important to think of AG use as an integral part of the application
design and not as something that gets tacked on at the end of the
development process.

Programs that share an activation group implicitly share resources with each
other - that's the point.

>It came back from Fall COMMON 2001,
>to use an activation group for as
>long as the user is signed on the
>system and delete the AG when the
>user signs off.  What's the best
>way to handle it?

Ahhhh 'best way!'  The definitive answer is: 'it depends.'  As Jon Paris
says, 'AGs are friendly - keep them around as long as you can.'  The machine
cost to create/destroy an AG is roughly the same as starting/ending a job.

Given that programs running in the same AG share resources, what's your
application look like?  Do you have commitment control, shared ODPs,
overrides or static storage to worry about?

>It was also recommended at COMMON to NEVER mix
>OPM and ILE, so we've avoided the situation.
>But, from what I've read in this thread,
>others are doing it without any significant
>problems - as long as a NAG (QILE) or
>*NEW is used when the ILE program is called.

The hassle is when a NAG program (including *NEW or *CALLER from a NAG)
establishes overrides/static storage/commit control boundaries and expects
that OPM programs will be able to inter-operate.  They won't.  That's the
point of a NAG - programs running in a NAG share resources with each other
but NOT with programs running in other AGs, including DAG.

  --buck