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



Hello Charles,

The SP's do use the very common files but only for read purposes. So I
do not worry about it that they are kept open, and commitment control is
out of scope.
A few applications have named AG's in my shop, but for most of the other
applications I won't hussle around with reclaiming resources. And I
don't want to keep the application AG's alive after use, they have too
much update files under commitment control, so I want the system to
automaticly clean up after use.

Kind Regards, 
Arco Simonse


-----Oorspronkelijk bericht-----
Van: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] Namens Wilt, Charles
Verzonden: woensdag 18 mei 2005 16:56
Aan: RPG programming on the AS400 / iSeries
Onderwerp: RE: size of activation group

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

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

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



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.