"The term originally referred to what is now usually called virtual memory"
And seems to lead on to memory mapped files, so nothing apparently significant AFAICS.
I'll check out your slic link, thanks.
The truth is, most of us that worked on top of OS/400 do not really know what a lot of this means ... just that it is good because IBM told us it was :)
In a way, that is what made this a great place to develop applications. You work in RPG (some use COBOL) in languages that are purpose built for working with the built-in database and do not worry about things like memory and where things are stored. The runtime environment and OS handle those details.
I was employee 1 at an ISV that made "Change Management" application, what would we be called DevOps today. The way the OS treats everything as objects that have properties we can manipulate and move around was just cool. It was just so straight forward to manage the applications people were creating and deploying, it is hard to explain because it is very different from the *nix/Windows world of how it is done. Even mainframe is not quite the same.
The overall system was ahead of its time in many ways. Recall arriving at work in AM (tiny company in a small town) and walking in and having our IBM rep also arrive. Ask why he is there? The system phoned home (via mode) to let IBM know a disk was failing. He has replacement with him to swap in.
These systems were expensive, especially for a small company. Recall we had to get a loan so we could buy a tape drive for $25K so we could then put our software onto $50 tapes that we had to mail to customers to let them try or update the software. Some of our bigger customers needed their tapes on a drive that was more like $100K to buy. Thankfully, there were other AS/400 customers within driving distance that would let us come over a couple of times a month and copy our software onto tapes using their drives.
When CD-ROM finally became standard it became a god-send for our business.
"With a single-level storage the entire storage of a computer is thought of as a single two-dimensional plane of addresses, pointing to pages. Pages may be in primary storage (RAM) or in secondary storage (disk); however, the current location of an address is unimportant to a process. The operating system takes on the responsibility of locating pages and making them available for processing. If a page is in primary storage, it is immediately available. If a page is on disk, a page fault occurs and the operating system brings the page into primary storage. No explicit I/O to secondary storage is done by processes: instead, reads from secondary storage are done as the result of page faults; writes to secondary storage are done when pages that have been modified since being read from secondary storage into primary storage are written back to their location in secondary storage."
IOW this is classic VM behaviour. Which bit of the wiki article is revelatory?
(NB. I've actually used multics).
With single level store, the program pages are mapped in, not copied. Writing to the page alters the disk image. All processes running the same program share the memory pages.
Umm, mmap'ed files on linux allow both https://www.man7.org/linux/man-pages/man2/mmap.2.html
MAP_SHARED
Share this mapping. Updates to the mapping are visible to
other processes mapping the same region, and (in the case
of file-backed mappings) are carried through to the
underlying file. (To precisely control when updates are
carried through to the underlying file requires the use of
msync(2).)
MAP_PRIVATE
Create a private copy-on-write mapping. Updates to the
mapping are not visible to other processes mapping the
same file, and are not carried through to the underlying
file. It is unspecified whether changes made to the file
after the mmap() call are visible in the mapped region.