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



Jon,

When I read your answer at point 3 over again, I think to find more in
your answer than I first saw. (Sorry my natural language isn't English
so it takes longer before the light goes on)

Are you saying that:

a) Calling an already initialized SP from another AG takes more handling
than calling a SP in the same AG? 
 
b) Using *NEW AG's for the applications is somewhat unusual? The
applications that are often reused in a job have named AG's in my shop.
For the other applications I like it that the system cleans up by itself
after ending the application. Thats why I choose *NEW. Maybe not a good
approach?

Thanks, Arco Simonse
 

-----Oorspronkelijk bericht-----
Van: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] Namens Jon Paris
Verzonden: woensdag 18 mei 2005 16:40
Aan: rpg400-l@xxxxxxxxxxxx
Onderwerp: RE: size of activation group

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 ?

The best advice I've heard from the Rochester experts in recent years
has been that the OS is now so good at optimizing virtual memory usage,
that most of the time we do more harm by worrying and fixing than if we
leave it alone.  I have never heard of AG size being an issue.  The
system will deal with it.

 >> 2) Do activation groups have a size limit ?

Not aware of one, but I guess there must be one somewhere - but I doubt
I'll ever hit it in my lifetime.

 >> 3) Are there any other problems that I do not foresee?

The usual one is that of course the files used by the SPs remain open
for the life of the job.  Only you can tell whether this is a problem.

In terms of performance, understand that there is a small performance
penalty paid on each call to the SP routines.  If they are called
millions of times there is the potential that you will use more
horsepower than you save by avoiding firing them up in *New AGs.  Of
course it is spread out over the life of the application so it has less
impact on the user than the all-at-once effect of firing up the SP.
Since I don't know what your usage patterns are .....  The fact that
*New doesn't cause you a performance problem probably means you've got
more than enough horsepower available to not worry about it.

Net - don't sweat it unless experience indicates a problem.

Jon Paris
Partner400

www.Partner400.com
www.RPGWorld.com


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