Re: Using activation groups

[Srinivas.Rao@xxxxxxxxxx (by way of David Gibbs <david@xxxxxxxxxxxx>)]

     Hi David !

     The way we are using activation groups is
     1. put  *dftactgrp on all the programs ILE & OPM.
     2. If an ILE pgm need to be invoked in its own commitment boundary and
               overrides, etc. We put that program in a *new or named
               activation group which ever make sense. Remember when *new
               is used, it is automatically deleted when the call ends and
               the control goes back to the application.
     3. If an ILE pgm need to be invoked in the calling application
               commitment boundary and overrides, then we use *caller. The
               application calling it may have *dftactgrp or *new or named
               activation grp.

     The activation group is only applicable to the job or session. It can
     not share the same activation invokation by another job or session. So
     within your job, you can segment the invokation of programs.

     srinivas.rao@ipaper.com





______________________________ Reply Separator
_________________________________
Subject: Using activation groups
Author:  midrange.com!midrange-l-owner@mcs.com at INTERNET
Date:    1/15/98 8:45 PM


I was wondering how people are defining activation groups.  We originally
planned to use *CALLER for all programs and service programs and set the
activation group based on our menu interface program.  Depending on
environment
and authority we call an interface program from our menu.  We intended to
assign our activation group based on the interface program's activation group.
In this way we could completely separate test/production and
payroll/financials/other.  We didn't think about QCMD and PDM.  Quite a bit of
testing goes on where calls are made from these programs.

We have four options at this point.  1.  Get IBM to allow a dynamic activation
group. Highly unlikely.  2. Specify an activation group on all of our
programs.
All programs would have to be duplicated in test/production environment.  3.
Create a new interface program that would be called when testing that would
use
our menu interface program to complete the call.  This requires out
programmers
to be more disciplined.  4. Some option we haven't thought of yet.  This
requires

How have you dealt with this?    An option to specify ACTGRP(*CALLER/*NEW if
caller default) would be perfect.  Of primary concern is the ability to
prevent
test and production environments from overlapping.  Secondary is the
ability to
install a change (requiring a triggered RCLACTGRP) during business hours.  The
least important is the ability to reclaim resources as users switch between
job
area.   Being able to assume the menu program is a boundary is also nice to
have.

Thanks

David Morris

! !

 +--- | This is the Midrange System Mailing List! | To submit a new message,
send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list
send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to
the list owner/operator: david@midrange.com +--- uucp


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---