Re: Why separate pools? -- MIDRANGE-L

I was out for most of this discussion. However, it seems a little different
than I understand.

With the original program model (OPM), there was the ability to load a
program once into memory and share it between the running jobs that needed
it.
When the ILE came along, with activation groups, I remember the difference
being that each job needed a copy of the program in memory for itself. Which
meant more memory, etc...

So, to a single job, it appears as though the program exists only in one
place - the memory it has been allocated. If the part of the program is not
there, it will page it in from disk to memory so it can be run.

This seems to be different than all the conversation so far - where am I
missing the point?

- Trevor


----- Original Message ----- 
From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, November 24, 2004 5:33 AM
Subject: Re: Why separate pools?


>
> On 24/11/2004, at 10:10 AM, Joe Pluta wrote:
>
> > Not to me.  When an object is read into memory, it by definition
> > resides
> > in two places at one time, no?
>
> Yes and No. Below the MI parts of the object exists in two places; the
> entire object out on DASD and one or more parts of it in main storage.
> At the MI level where OS/400 applications operate there is only ever
> one copy of an object. When part of an object is paged in to main
> storage the virtual address tables are manipulated to address main
> storage. That means part of the object is found on DASD and part is
> found in main storage but only one object exists.
>
> SST and other things that operate below the MI can still find the
> original object parts that are on DASD but that's not really what's
> being discussed here because those parts are not in use.
>
> This behaviour of only ever having a single copy of a given object is a
> direct consequence of single-level-store. To illustrate, on Unix and
> Windoze when you run a program the entire thing is copied into virtual
> storage. It is then paged into main storage from virtual storage as
> needed. It is possible to delete the program object from disk while it
> is being used and still continue to run the copy in virtual storage.
> Therefore two copies of the program.
>
> On OS/400 when you run a program only the first chunk is copied into
> main storage. If you delete the program from DASD only the current
> instruction will continue to run. When the system moves to the next
> instruction it will run into the MCH3402 - Tried to refer to all or
> part of an object that no longer exists. Therefore one copy of the
> program.
>
> > There is a clear difference between virtual memory (the huge address
> > space that single level store inhabits) and physical memory.  There is
> > a
> > map that indicates where on disk a given virtual address space resides,
> > and that's what the single-level store is about.
>
> Physical 'memory' doesn't really exist at the level we deal with. It is
> all single level store and in that environment main storage is just a
> giant cache for DASD. So very unlike Unix and Windoze. The distinction
> is somewhat blurred because we can manage main storage pool sizes and
> we can explicitly load objects into main storage using SETOBJACC. Those
> controls are provided for performance reasons and don't really affect
> the underlying principles. They are really just a way to manage the
> cache that is main storage.
>
> Single level store maps both main storage and DASD as one big address
> space. The virtual address tables translate virtual addresses to
> physical addresses. Some physical addresses will be in main storage
> others on DASD--even for a single object. At the MI level all addresses
> are virtual addresses. It is only below the MI that a distinction
> exists between main storage addresses and DASD addresses.
>
> Single level store is not about mapping disk space--it is about making
> main storage and DASD appear the synonymous.
>
> > Then there's the paging mechanism, which tells you whether a copy of
> > the
> > object already resides in physical memory.  Here, there is a difference
> > depending on whether the object is read-only or update-capable.  I
> > could
> > see a problem if the object was write-capable and in two locations, but
> > it seems to me that a program object is not write capable (that's why
> > programs get "moved" to QRPLOBJ when you compile new versions).
>
> Paging doesn't tell you where an object exists. Paging copies data (or
> moves if you prefer) between main storage and DASD. The paging process
> also causes the virtual address tables to be updated to the real
> address which reflects the current location. If a virtual address is
> found in the primary directory then it is in main storage otherwise it
> is on DASD.
>
> Program objects are no different from other objects. The code is demand
> paged into main storage once only. It makes no difference that it is
> "read-only". Each object has only one address so how could it possibly
> be found if loaded multiple times in difference storage pools?
>
> Programs are mostly not "write-capable" but that's not why they get
> moved. They get moved because there is no lock on them to indicate they
> may be in use and replacing (i.e., deleting and recreating) will cause
> jobs using the program to get MCH3402. Try it. You'll have a "learning
> experience" which is exactly what used to happen on S/38. Recreating an
> object always results in the new object getting a new address. It never
> replaces an existing object of the same name and type. Any existing
> object is either deleted or moved to QRPLOBJ. It is the fact that each
> object gets a single permanent virtual address that allows the 'move'
> function to work. The object is not moved, only its context changes.
>
> > Anyway, we're probably guessing and you're just as likely to be right
> > as
> > I am.  Like I said, maybe someone from IBM can enlighten us.
>
> No guesswork at all.
>
> Regards,
> Simon Coulter.
> --------------------------------------------------------------------
>     FlyByNight Software         AS/400 Technical Specialists
>
>     http://www.flybynight.com.au/
>     Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
>     Fax:   +61 3 9419 0175                                   \ /
>                                                               X
>                   ASCII Ribbon campaign against HTML E-Mail  / \
> --------------------------------------------------------------------
>
>
> --
> 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.
>
>