The Pankian Metaphor 3100

tss-360 enable 32-bit virtual addressing.

part of the issue in virtual machine operation ... was doing i-o. all the 360 i-o operations were 24bit ... i.e. you couldn't do an i-o operation into an address other than 24bit.

tss-360 provided 32-bit virtual addressing within a "real" 24-bit machine (i.e. all i-o transfers, to-from disk, etc ... all involved 24-bit addressing api). you could operate within a 32-bit virtual address space ... but when you went to actually do something it was restricted to 24bit.

cp67 could provide a virtual machine for tss-360 to run in with 24-bit ... since the "real" machine that tss-360 ran in was 24-bit.

besides cms being constrained by heavy borrowing of software from os-360 world ... its api for moving to-from filesystem was 24bit inherited from the 360 "real" i-o infrastructure.

when i built page-mapped filesystem for cms, i went to a 32bit api (actually slightly more than 32bit address since i used 32bit field to specify 4k page numbers ... so theoritically it was 32bit+12bit ... 44bit api).

however, the rest of cms was heavily 24bit.

in the os-360 world, even after 370-xa and 31bit was introduced ... there was heavy use of dual-mode operation because of the enormous amount of inherited 24-bit software.

general motors research was a big tss-360 32bit user on 360-67 ... they claimed that they got enormous programmer productivity using the tss-360 single level store model (large memory mapped files) in 32bit mode ... with the programmers not having to bother themselves with a lot of file semantics found in many applications.

--