× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Chuck.

To answer your question, the application
is submitted by the standard job scheduler
and ends when system time passes the time
stored (hh:mm in 24:00 fmt) in a data area
read by clle_1 at the start of each loop.

In the case the data area time value is less
than job start, end time is assumed to occur
the next day.

In the past I've used AG names unique to the
application but now it seems better to let
the system gen the AG name and for programs
called by the job clle_1 to use *caller, and,
as others admonish, use COMMIT/ROLLBACK.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, February 03, 2014 2:36 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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.

--
Regards, Chuck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.