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.