|
I admit I don't have an exact understanding of local variables memory
management, but my understanding was that if I have a procedure called a
thousand, million, etc times, I should define its local variables as Static
so it's note uselessly fiddling with memory every time it's called.
That line of thought seems to conflict what you're saying.
If I'm going about this incorrectly I would love to know because we run
high volume data processing.
Thanks,
Kurt Anderson
Sr. Programmer/Analyst - Application Development, Service Delivery Platform
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Alan Campin
Sent: Sunday, July 12, 2015 8:11 AM
To: Midrange Systems Technical Discussion
Subject: Re: How does the i handle programs in memory using different
methods?
Big subject.
First of all, whether you combine depends on what the other 2 programs
that get called are doing.
Are they providing services? Do many people call them? If yes, then they
should be service programs with exported procedures to provide services.
If not, combining them could be a good thing.
As far as memory is concerned, all static memory is initialized when a
module is first entered. If you have a module that never get called, its
memory will never be initialized and set to defaults.
Once it is initialized, it will stay in memory what happens to it depends
on what kind of object and if program, what type.
If service program, static memory stays either the job ends or the
activation group. If default activation group, when job ends.
If a regular RPG cycle program, memory get dumped when *INLR is turned on.
If not turned on, stays until either job ends or activation group. Default
activation group when job ends.
If a RPG Main program, LR means nothing. Static memory will stay until
either the activation group ends or the job ends. Default activation group
when job ends.
You have no control over what the system does with memory except by
dynamically allocating and releasing or ending an activation group.
The system is working constantly trying to get rid of excess memory and it
takes a lot of resources. The more static storage that a program has the
slower it is going to run, the more work the system has to do to manage it.
If it sees some memory not be touched out to disk it goes and then if you
reference it, back into memory it goes. Expensive.
This is why you want programs written as small procedures that memory is
created and destroyed as needed and as little static storage as possible.
Big programs with hundreds of variables in static storage are killers.
My goal is always to have zero static variables. I am always looking to
how I can reduce it.
Oh, well, now the hornets nest starts.
On Sun, Jul 12, 2015 at 2:17 AM, Wilson, Jonathan <
piercing_male@xxxxxxxxxxx
wrote:
An odd question occurred to me while playing around with some code.--
How does the i handle individual invocations of a list of programs
with regard to a simple call verses all of the programs compiled into
one massive single program?
If I have a program that calls another program that calls another
program (say a menu program calling WW-customers calling ww-customer
types) I now have 3 programs on the call stack. Does/can the i decide
that as the first two programs are no longer actively running, they
are effectively paused until return from the last most called program,
they can be good candidates for the i equivalent of paging?
Does the i even care what part of a program or variable is in or out
of memory or does it use some kind of "well that bit hasn't run for a
little while/long while/very long while" and just shift accordingly
having no knowledge of the state of a program within a stack of calls?
If, however, I was to write the programs as say three service programs
or three modules and then link them into one massive "pc application"
style program how much difference would there be as to how the i would
handle such a program in comparison to the first example?
Also the start up of "a program". I can't recall if the i loads all of
the program and initialises all of its variable memory when a program
is called, or if it just loads chunks of code and then initialises the
variables the first time it comes across them, or even some
combination
- perhaps something totally different - of the above.
I understand, as far as I can recall, the concepts of the single level
storage where everything is just an address with the OS handling the
details of if the address is in memory or on disk etc. But at some
point for a newly started program the variables used must be set up to
be unique to the user/job/etc. running the program so until that point
the memory of the programs variables have no address... after that the
variables can be dealt with by the single level storage, in memory, in
NVRAM, on SSD's or on good old spinning disks.
I'm guessing, but might be wrong, that the actual program (real good
old honest logic code) in its non active state looks no different to
the program once its in an active state so the program "code" fits
nicely into the single storage level concept so there is no overhead
of un-packing code from its on disk structure to its in memory footprint.
I also can't remember if the "loaded" program is loaded once but
points to unique data per job, or if a job running a program has a
unique copy of both the code and the variable memory.
While writing the above, something niggled at the back of my memory
that said the first time a variable is accessed it gets a fault saying
something like "not initialised" which differs from a "not in
memory/page" fault... but I might be wrong it was so long ago that I
read up on it.
Jon.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
