Re: AS400/i5 etc general behaviour

Hi, Walden:

See my embedded replies below.

> Walden H. Leverich wrote:

The difference between the single level store the i uses and the swap
file system used by other systems, is that when the i swaps data out
of memory, it only exists in one place on disk. Whereas with other
systems, data is swapped out of memory into a specific swap file on
disk plus the original copy of the data still resides on the file
system.

That really depends on the nature of the page being swapped out. Say you
fault in a page of an RPG program, and then the machine needs to use
that memory elsewhere, the i will simply drop that page on the floor
since it knows it can read that page from disk again. BTW, other OSs
will do that too. If Windows needs to swap out a DLL it will simply drop
it on the floor, it doesn't need to save it to the swap file.

OS/400 will overwrite the real storage frame without first saving the previous page contents on backing store (DASD).

However, if the memory page you're working with has modifications then
the i has to swap that page out to some sort of swap file as it can't
reload it from disk as the changes haven't made it to disk yet (and
might not ever do so). Likewise, if you've changed a page in memory on
Windows and windows needs that memory it has no choice but to write it
out to swap.

In "Single Level Storage" as implemented by CPF, OS/400 and i5/OS, there is nothing like a "swap file" anywhere in the architecture. There are only MI objects existing in single-level storage; that is to say, they have a SLS address (128 bits or 16 bytres long), aka. an MI pointer. They may optionally have a "name" in CPF or XPF, but that is mostly done "above the MI" layer. When an MI object is created, it is designated as either "temporary" or "permanent", which controls whether they will persist across an IPL boundary. Once assigned a virtual address (MI pointer), and real DASD pages get assigned and allocated to that object, these pages never "move around" -- if paged in, and then later paged out again, each page will go right back where it came from -- to the same DASD device and block where it "resides".

Windows uses a "swap file" (an actual file on contiguous disk sectors) purely as "extended memory" -- that is, if there is not enough room in real memory for all of the pages currently needed, then Windows will start to "swap" some pages to the swap file to "make room" for other pages (in real memory). These are still only "in virtual memory" pages, and not the images of pages that also reside permanently on disk somewhere else (in a disk-resident file system).

Of course, the nature of i programming makes it less likely you'll
modify pages of information as most things can't be changed by a
programmer.

A typical OS/400 application, let's say, an RPG program, reads a row from a table, or a record from a file, (in OS/400, they are the same thing). What happens is, the data management layer, having opened the file object, and resolved to the virtual address in SLS, now has pointers to the data space and data space index MI objects, so it can use MI instructions like FNDINDEN (find index entry) to search that index, and get a "pointer" to the corresponding "row" or record of data in the data space (in what is called a "cursor"). There are no "FILEs" in the traditional sense; there is no "read" and "write" of each individual record or row directly from disk -- there is only demand paging-in of the pages of the data space that contain the desired rows or records. The data management routines (QDBGET, QDBPUT, etc.) use special database MI instructions to copy the data from the data space to the application program's buffers. Similarly, if the application writes or updates a row or record, the database management layer uses special MI database instructions to copy the updated record data in the program's buffers back to the appropriate places within the data space. Then, eventually, (only) the "changed" pages of the data space will get "paged out" back to their permanent locations on DASD (unless you force "flushing" of changed pages to disk, e.g. using the FRCRATIO parameter of the CHGPF command, which causes the changed pages to get written back to disk right away, with a penalty of some performance loss for the application, which must wait for this actual disk I/O to complete, before it can continue.)

Note that there is no concept of a "file" residing on a single DASD volume, or even on contiguous disk "tracks and cylinders". OS/400 will try to spread the pages of an MI object (like the data space) across as many DASD arms and heads as possible, within the same ASP (Auxilliary Storage Pool), so that it can take advantage of parallel I/O available via multiple IOPs and IOAs, to bring in (or write out) as many pages of the data as needed, as quickly as possible. The AS/400 has always had a hierarchy of microprocessors (IOPs and IOAs) all working on various tasks within the system, to improve the overall thruput and performance of the system as a whole. That's how the relatively slow IMPI CISC AS/400 processors were able to handle as many users and transactions as they did, in their day.

-Walden

I hope that helps to clarify some things for some folks.

Mark