Re: Activation Group design question

On 03-Feb-2014 12:45 -0800, Gary Thompson wrote:

I have program clle_1 currently in pilot, and am reviewing
activation group design to get correct function with good
efficiency.

One concern is file updates made by program sqlrpgle_1 must be read
by programs sqlrpgle_2 and sqlrpgle_3.

clle_1 runs as a (almost) never-ending program, meaning it
runs in a loop for about 24 hours, ends and re-starts minutes later.

<<SNIP>>

My new activation group design:

Leave clle_1 set to *DFTACTGRP

Change sqlrpgle_1 from activation group QILE to *NEW
(to force updates to be "posted", assuming that with a *NEW
activation group, when sqlrpgle_1 returns with LR=*ON, file
updates "take effect" similar to FEOD ?)

Change sqlrpgle_2 from activation group *NEW to *CALLER,
Different than the *NEW activation group created by sqlrpgle_1,
for same reasons mentioned for sqlrpgle_1.

That is a combined total of some 1,400 activation group
create/delete steps per day.

All suggestions/comments gratefully welcomed . . .

IMO, definitely avoid CLLE_1 using DFTACTGRP(*YES); esp. given any invoked [esp. service] programs having ACTGRP(*CALLER).

I would create CLLE_1 with a named activation group, and create each of the other called programs named SQLRPGLE_# either to have ACTGRP(*CALLER) or to have a named activation group that could be either the same or different than the name chosen for CLLE_1. If the SQLRPGLE_# are created with *CALLER as their activation group, then creating the CLLE_1 with its named activation coming from ACTGRP(*NEW) is little different than an explicitly named activation for CLLE_1 [given CLLE_1 is the first program in the stack and the only place that program will appear in the stack; i.e. not called again\recursively]. Whether the system generates the name of the activation at run-time or whether the name is given explicitly at creation-time, is immaterial in that scenario. However whether that scenario matches the given scenario is unclear, for lack of a definition of how the application starts and re-starts.

The visibility of the changes to the data, as performed by the SQL, remains the same, irrespective the value of *INLR upon RETURN. The choice of whether to set *INLR=*ON should be based on the desired effects for the non-SQL processing of the RPGLE; e.g. if some non-SQL file opens would benefit from being able to use the same ODP rather than effecting a full-open on each of repeated invocations.