• Subject: Re: Which activation group to use (was "Procedure failing")
  • From: bmorris@xxxxxxxxxx
  • Date: Thu, 9 Dec 1999 10:17:47 -0500




>Date: Wed, 8 Dec 1999 13:15:00 -0500
>From: "Mark Walter" <mwalter@netrax.net>
>
>Barbara,
>
>Would the proper thing to do be to compile the service program utilizing
the
>QILE activation group? Or something else?

Mark, choosing an activation group name is a bit like choosing which
library a program should go in, although it's a bit more complicated.

First of all, you don't have to create an activation group, so you can use
whatever name you want.

Put things in the same activation group if:
- they should share activation-group-scoped resources like overrides,
commitment control, static storage

Put things in different activation groups if:
- their access to resources should be private

Put things in *CALLER if
- the way the functions in the service program work depend on previous
calls, and callers from different activation groups should not affect each
other
- either all callers are from non-default activation groups OR it doesn't
matter if the service program runs in the default activation group

Other considerations if none of the above considerations apply:
- using *CALLER means that calling the service program will never require a
new activation group to be created
- using a named activation group that is private to the service program
(usually the activation group has the same name as the service program if
this is the case) means that the activation group has to be created the
first time it gets called in the job
- using *CALLER means that there will be multiple copies of the static
storage of all the modules in the activation group - this not only impacts
runtime storage consumption, it takes time to do all these initializations
- using *CALLER (as you have found out) means that it's possible for the
service program to run in the default activation group, which can cause
problems
- since QILE is a default, it has the advantage that it is likely to have
already been created when your service program needs it; it has the
disadvantage that other applications that you don't even know about might
be using it - that might not be a problem unless they are destroying the
activation group, or unless you have resources that you don't want shared

As always, don't let minor performance/storage considerations determine
your choice *unless all other things are equal*.

Barbara Morris


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


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.