RE: Activation Groups/SQL Suggestions

2 - We used to use just DFTACTGRP(*NO) in our H-Specs, now we also
use ACTGRP(*CALLER)

Good and bad. Good if the root program (i.e. the one effectively
called from the command line) is a real ILE program with either ACTGRP
(*NO) or ACTGRP(somenameorother). Otherwise *CALLER just results in
running the program in the default activation group and that will
bite you in the end. Apart from anything else it will prevent you
from cleaning up programs and files without signing off. See 3 below.

Would this work?

The menu program runs in the DAG.
ALL programs called from the menu specify DFTACTGRP(*NO) ACTGRP(*NEW) or
ACTGRP(<name>).
All other program specify DFTACTGRP(*NO) ACTGRP(*CALLER).

Rob
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jon Paris
Sent: March 19, 2008 10:18 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Activation Groups/SQL Suggestions


On 19-Mar-08, at 3:30 AM, rpg400-l-request@xxxxxxxxxxxx wrote:

Here is what we have done so far:
1 - When we convert an OPM to ILE, we also convert any called
programs to ILE

Good

2 - We used to use just DFTACTGRP(*NO) in our H-Specs, now we also
use ACTGRP(*CALLER)

Good and bad. Good if the root program (i.e. the one effectively
called from the command line) is a real ILE program with either ACTGRP
(*NO) or ACTGRP(somenameorother). Otherwise *CALLER just results in
running the program in the default activation group and that will
bite you in the end. Apart from anything else it will prevent you
from cleaning up programs and files without signing off. See 3 below.

3 - In our main menu program we use RCLRSC(*) when a menu option ends

This is basically doing nothing. RCLRSC is completely ignored by ILE
programs. _If_ you are running your ILE programs in an ILE AG then
you want RCLACTGRP.

4 - In SQL programs we have started using *ENDMOD to close the
cursor (either at compile or using 'Set Option' in SQL)

OK - that's fine.

| It did not seem to reduce the number of opened files, and we even
have one app that refuses to run when compiled with *CALLER.

You haven't done anything to deal with the files - see 3 above. Can
you define "refuses" - _any_ program can run *caller - the _why_ it
doesn't run will show us how to cure it.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com