Hi, Tom:
Back on the CISC IMPI machines, the page size was only 512 bytes, now it
is 4096 bytes on RISC PowerPC ... and the real main storage size on IMPI
machines was measured in Megabytes, not Gigabytes... in the mid-1990s,
128 MB of real main storage was considered "large" ... :-o
It is truly amazing to consider that OS/400 could run comfortably on a
smaller model IMPI CISC machine with only 16 MB of real main storage.
Also, you could set the PURGE(*YES) vs. PURGE(*NO) attribute of a job,
either via the *JOBD or via the CHGJOB command, and this meant that the
job was "eligible to be purged" when set to *YES, if the job went into a
"long wait." There used to be something called the PAG (Process Access
Group) that identified the "objects" (many were "internal" MI objects
used internally by the job) that could be "swapped out" and "swapped in"
together, for performance reasons. IBM got rid of the PAG competely a
few releases ago. So, I don't think PURGE(*YES) actually does _anything_
any more ...
Newer RISC PowerPCs have very large real main storage sizes, measured in
gigbytes, so swapping is no longer needed. What happens is, while a job
is inactive, its pages could get "stolen" (paged out to make room for
other pages) if there is enough "pressure" on that particular storage
pool where that job is running. That's why OS/400 has always allowed
the customer to partition real memory into various private pools, per
subsystem, so you could have some control over its usage. Also that's
why IBM does not recommend that you just run everything in QBASE (with
all interactive jobs plus all batch jobs, competing for the same memory
pages.) Sadly, I often find OS/400 shops that have "no idea" what's
going on, and never changed _any_ of those defaults, and still run the
system as delivered, "out of the box." It's amazing it works as well as
it does, with NO tuning (by a human, but only what the system does
automatically, e.g. with QPFRADJ).
OS/400 is truly a "paging" system; it never was really a "swapping"
system. The closest thing was the idea where, back on IMPI CISC
machines, where the total main storage size might be only 16 MB or 32
MB, when a job entered a "long wait", the system would then check each
object in the PAG and flush out any changed pages, and then mark all
those pages occupied by those objects as "available" page frames, that
could be used to page in new pages. If no other jobs were needing new
pages, in the same storage pool, then none of those pages would
actuallly get "stolen" and when that job "wakes up" from its "long
wait", everything could pick up and continue running again rather
quickly, because all that stuff was still in main storage. It is only
when the degree of multiprogramming is too high, relative to the size of
the storage pool, that demand paging causes those pages to get stolen,
and so then, to start that job up again required paging out other stuff
to make available page frames in real main storage to page in those
needed pages again. That could take a while, and was called 'swapping'
-- but it was NEVER the kind of wholesale "swapping" you are likely to
see on some other systems with virtual memory, like IBM's mainframe MVS
- OS/390 - z/OS systems.
Again, with today's System i, with very large main storage sizes, paging
should not be much of a problem, unless you artificially constrain the
size of the storage pool for some subsystem, and then run too many jobs
in that same pool with too high an activity level (in other words, "the
degree of multiprogramming is too high"), causing "thrashing". Real
main storage is just a "cache" for recently used pages, which reside
permanently on DASD, as part of the "single level storage."
Hope that explanation helps someone...
Mark
> Tom Liotta wrote:
Nathan Andelin wrote:
It may be one thing to swap out a 2 meg RPG job, but another thing to swap out a 64 meg PHP job.
That'd be especially true if only a few pages of the "2 meg RPG job"
were swapped out. AFAIK, System i (etc.) swapping happens more at
the page-level than the job- or program- or even object-level. ICBW!
Tom Liotta
midrange.com
