× 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 Nelson,

You wrote:
>I still have over 500K in static storage to deal with though, so I think I
>need to put more effort on reducing that side of things, now.  As a
>combined program, I assume each user will get all 500k allocated to them
>each time they call the program.  If I use the 12 program model, only 4
>programs would always be called and the other 8 would be called less
>frequently (this fits the 80/20 rule fairly well).  If the first user (or
>some user) has all 12 programs active, will each additional user that
>calls, say, the first program only get only the variables associated with
>the first program or all 500k?

Storage is allocated only as each program is called in a given job.  The
fact that job A has allocated all 500k has no effect on the storage required
by job B.

>Another question:  The initial call to this system is to a cl program that
>runs in *CALLER and saves everything (libr lists, lda, etc) about the
>caller's environment and then calls this program(s) which run in their own
>named activation group.  On termination, the cl reclaims that activation
>group and restores the caller's original environment.  If a second user, in
>another job, is using the program code reentrantly (is that a word?), what
>will happen when the first user's job tries to kill the activation group.

Nothing.  Jobs are isolated.  The activation group in the first job is
destroyed and nothing happens to the activation group in the second job.
The exception is shared activation groups but since user code can't create
them we don't have to worry about them.

>Will the rclactgrp command be ignored because some other job is using the
>code?  I guess I don't understand the relationship between the program code
>in an activation group, which is part of a job, and the other user's use of
>that same code in memory.

The code is not in the activation group.  The program variables are -- along
with temporary data management resources, dynamic storage (although the
heaps themselves are not), and linkage information.

>Does each user's activation group only contain pointers to the code and not
>the code itself?  If so, I guess blowing away one activation group would
>not effect another user's activation group that is using the same code. Is
>this the way it works?

>When I broke up the one program into 12 separately compiled programs, I
>gave them each their own activation group name with the thought that I
>could reclaim the lesser used ones when the user was finished with it and,
>thereby, keep the total size down.  Do you think this is still a good idea?

I wouldn't bother with separate activation groups unless you are really
strapped for main storage.  Also, it is not a really good idea to be
constantly creating and destroying activation groups.

The ILE Concepts manual explains this stuff very well and is written in
manner condusive to easy reading.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   «»
«» Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   «»
«»                                                           X    «»
«»               ASCII Ribbon campaign against HTML E-Mail  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»


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.