RE: Paging file -- MIDRANGE-L

| -----Original Message-----
| [mailto:midrange-l-admin@midrange.com]On Behalf Of James Rich

| On Tue, 29 Oct 2002, Hans Boldt wrote:
|
| > others. But since all processes in an SLS architecture share the
| > same (humongous) virtual address space, you need some means of
| > ensuring that a process really is allowed to access a particular
| > region of store. That puts more overhead on securing memory
| > accesses, which requires substantial capabilities in the CPU itself.
| > It also meant 16 byte pointers, which can increase memory
| > requirements. If you remember back to the early days of the S/38, it
| > had significant performance problems, which adversely affected the
| > way system programming was done. (There *were* some very good
|
| In addition to this it seems to me that there is another performance
| problem with single level store.  I don't know this for sure but it seems
| right.  If an object in main memory needs to be pushed back to disk
| because memory is low, it is written back to its original location on
| disk.  Then when it is retrieved back into main memory it is read again
| from that spot on the disk.  This is ineffecient use of disk, as these
| reads/writes will be all over the place instead of in a closely clustered
| area of disk.

James,

Leaving aside the supposed inefficiencies of disk and cache (and L1, L2, Lx)
memory, and all that, in a previous post You wrote:

| -----Original Message-----
| [mailto:midrange-l-admin@midrange.com]On Behalf Of James Rich
| Sent: Saturday, October 19, 2002 2:06 AM
| To: midrange-l@midrange.com
| Subject: Re: V5R2: Source now allowed in the IFS
| Importance: Low
|
|
| On Fri, 18 Oct 2002, Mark Waterbury wrote:
|
| > The real problem with all these IFS path names is that the path can
| > contain an arbitrary number of "levels" of subdirectory, before you
| > even get to the actual file name, which in and of itself can be very
| > long... the architected "limit", by the way, if you can call it
| that, for
| > IFS path names in OS/400 is 16 Megabytes! (16 million+ characters)
|
| I honestly don't know why anyone would care that the path to the original
| source is stored in the binary?  What is the big deal?  Being able to use
| the IFS to store source code adds a great deal of flexibility and opens a
| new range of options for working on the iSeries.  I don't see how "all
| these IFS path names" are a problem.  Please enlighten me.
|
| > Unix weenies in the Unix world rely on "naming conventions"
| > to find the corresponding source file for a given executable file.
| > Crude utilities like "make" rely on the file date/time stamps, using
| > the file system as a primitive database, to determine what changed,
| > and hence, what objects need to be recreated from "corresponding"
| > (by name only) source files.
| >
| > Why must we drag OS/400 down to this same level of functionality
| > (the "lowest common denominator") in the name of strict Unix or
| > Posix compatibility? Ugh!
|
| Easy there.  What to you is dragging down is to me raising up.

<snip interesting comments>

Thing is,

If You start with THIS conclusion and work backwards to the facts...

Then...

Else...

?

(It's what we ALL do frequently, of course.)


L8trz, debaters...;-D

jt