× 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.



Simonse,

The recommendation I usually see is to have service programs use 
ACTGRP(*CALLER).  As I understand it, this allows the service program to 
operated under the same commitment control definition as the calling program.

If you're service program are non-database related, in other words they aren't 
accessing any files I think a common AG would be fine.  But if they access 
files, I'd think I'd leave them as *CALLER.

Instead of messing with the service programs, have you considered changing the 
applications from (*NEW) to a named AG?

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Simonse, Arco (CMK)
> Sent: Wednesday, May 18, 2005 8:26 AM
> To: RPG400-List Midrange.com
> Subject: size of activation group
> 
> 
> Hello,
> 
> 
> I want to separate several serviceprograms that are often used by our
> applications. These srvpgms do very common things, like 
> getting customer
> info, article coding info, stock info, selection subfile windows, etc.
> Until now I always compiled these serviceprograms with ACTGRP *CALLER,
> and the applications that use these servicepgms are always 
> compiled with
> *NEW or sometimes in a named ACTGRP. There are about 150 applications
> that often use parts of these 60 serviceprograms. So far so good. 
> 
> I realize that the dowside of this approach is that every time an
> application starts that was compiled with ACTGRP *NEW, it will
> initialize the almost same bundle of serviceprograms that were used in
> the previous executed applications.
> So what I want to do is to put these serviceprograms in a 
> separate named
> activation group, for example COMMONAG.. Then resources for these
> serviceprograms are initialized at once and remain available for all
> applications that are executed later.
> 
> The serviceprograms are optimized *FULL and about 700 - 900 Kb each.
> Total serviceprogram size is 48 Mb. Static storage is 11 Mb.
> 
> My questions:
> 
> 1) Does it cause problems when I keep this COMMONAG during the job's
> life with this static storage of 11 Mb and of course the ODPs 
> for about
> 40 files loaded ?
> 
> 2) Do activation groups have a size limit ?
> 
> 3) Are there any other problems that I do not foresee?
> 
> Any help would be appreciated.
> 
> Arco Simonse
> 
> DISCLAIMER:
> This message contains information that may be privileged or
> confidential and is the property of C.Meijer B.V. It is 
> intended only for the person to whom it is addressed. If you 
> are not the intended recipient, you are not authorized to 
> read, print, retain, copy,disseminate, distribute, or use 
> this message or any part thereof. If you
> receive this message in error, please notify the sender 
> immediately and delete all copies of this message. 
> 
> This footnote also confirms that this email message has been 
> swept by the presence of computer viruses
> 
> 
> -- 
> This is the RPG programming on the AS400 / 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 ...


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.