5 ms·

Seeing the headline, I wondered if the article would be about the IBM iSeries. Spent first 15 years of my career working on those, always a fond memory. Great m

Seeing the headline, I wondered if the article would be about the IBM iSeries. Spent first 15 years of my career working on those, always a fond memory. Great machines to develop traditional database apps on.

zasdffaa 4y ago
> Great machines to develop traditional database apps on Hi, could you explain what it was that made them so good to do this, thanks.
- lproven 4y ago
  Single-level store is a big thing. No other modern OS has or can do that. The integral database, too? https://en.wikipedia.org/wiki/IBM_i#SLIC https://en.wikipedia.org/wiki/IBM_i#SLIC
  - zasdffaa 4y ago
    A search for Single-level store gets me https://en.wikipedia.org/wiki/Single-level_store https://en.wikipedia.org/wiki/Single-level_store "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.
    - lproven 4y ago
      Single-level store is _nothing_ to do with virtual memory. That's a bad edit and can be ignored. Read the rest of the article.
      - zasdffaa 4y ago
        I don't understand that. Quite literally it is (or seems to be). In the 'design' section: "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).
        unused0 4y ago
        Non-single level stores are copy-on-demand. Typically, a process runs a program by starting with an empty address space and mapping the executable code into that space. The program is started, the first instruction fetched; the address space is empty a page fault occurs and the page is copied in. If the page is modified, that is local to the process and the disk image is unchanged. Each process has its own copy of writable pages. 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.
        zasdffaa 4y ago
        > 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 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. and AFAIK on Windows the same.
    - markphip 4y ago
      Try this link: http://www.varietysoftworks.com/jbaldwin/Education/single-level_store.html http://www.varietysoftworks.com/jbaldwin/Education/single-le... 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.

zasdffaa 4y ago

> Great machines to develop traditional database apps on Hi, could you explain what it was that made them so good to do this, thanks.

lproven 4y ago
Single-level store is a big thing. No other modern OS has or can do that. The integral database, too? https://en.wikipedia.org/wiki/IBM_i#SLIC https://en.wikipedia.org/wiki/IBM_i#SLIC
- zasdffaa 4y ago
  A search for Single-level store gets me https://en.wikipedia.org/wiki/Single-level_store https://en.wikipedia.org/wiki/Single-level_store "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.
  - lproven 4y ago
    Single-level store is _nothing_ to do with virtual memory. That's a bad edit and can be ignored. Read the rest of the article.
    - zasdffaa 4y ago
      I don't understand that. Quite literally it is (or seems to be). In the 'design' section: "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).
      - unused0 4y ago
        Non-single level stores are copy-on-demand. Typically, a process runs a program by starting with an empty address space and mapping the executable code into that space. The program is started, the first instruction fetched; the address space is empty a page fault occurs and the page is copied in. If the page is modified, that is local to the process and the disk image is unchanged. Each process has its own copy of writable pages. 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.
        zasdffaa 4y ago
        > 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 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. and AFAIK on Windows the same.
  - markphip 4y ago
    Try this link: http://www.varietysoftworks.com/jbaldwin/Education/single-level_store.html http://www.varietysoftworks.com/jbaldwin/Education/single-le... 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.