On 6/15/2025 10:39 AM, John Levine wrote:
According to Stephen Fuld <[email protected]d>:
like" functionality and the resulting overhead. IIRC the site specified
the size and number of user areas within TSO, and users competed for one
of those. It may be (I don't remember) that once a user program was
assigned to a user slot, if it got swapped out (by the TSO program), it
had to be swapped back into the same user area. This eliminated the
relocation problem we have been discussing. It was very slow with even
a few users.
Even without TSO, OS/360 had a feature called rollout/rollin which
swapped out a lower priority job to allow a higher priority one to use
more storage, then swapped it back in to the same place. I don't think
it was very popular.
Agreed. I think its lack of popularity was due to the requirement that
the (batch) program be rolled back in to the same physical location as
it was rolled out of. For batch programs, it seems hard to find a good
use case for this.
But TSO was for interactive programs, so swapping out one interactive
user while the user was "thinking" and letting another user use the CPU
and memory for that multiple seconds seems like a good idea.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)