The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Hunkeler Peter , KIUK 3) writes: > OS/360 was a real storage only operating system. DAT was introduced with > S/370. OS/390 could run on that hardware but not use DAT (and other > new hardware facilites). DAT was introduced on 360/67 ... basically 360/65 with dynamic address translation ... at least in its single processor version (although 360/67 offerred both 24-bit as well as 32-bit virtual addressing modes). The 360/67 multiprocessor did offer some additional features vis-a-vis 360/65 multiprocessor ... like all 360/67 processors could directly address all physical channels (while 360/65 multiprocessor was limited to addressing common real storage ... but didn't provide channel multiprocessor connectivity). tss/360 was to be the official operating system supporting 360/67 but ran into lots of problems and was decommited. however, the science center http://www.garlic.com/~lynn/subtopic.html#545tech did do a virtual machine monitor called cp40 for a 360/40 with custom hardware dynamic address translation modifications ... and then morphed it into cp67 when production 360/67 machines became available. cp67 was the precursor to vm370 when virtual memory support was announced for 370. the initial prototype for os/vs2 svs ... precusor to os/vs2 mvs ... was a custom modified mvt system ... initially running on 360/67 machines. it had hack on the side to create a single 16mbyte virtual address space and some simple interrupt handler for page faults. it also had CCWTRANS (and associated routines) from cp67 wired into the side to handle the application channel programs (from excp/svc0) to "real" channel program translation. This is an issue common for both virtual machine monitors and the os/vs genre of operation systems ... where the applications built channel programs that were then passed to be directly executed. The 360/370 genre of channels required "real" addresses for execution ... but the application (and/or virtual machine) built channel programs all had "virtual address" specifications. To handle the situation, a copy of the original channel program had to be created with the specified virtual addresses replaced with the corresponding real addresses. for other topic drift ... charlie's work on fine-grain locking supporting cp67 multiprocessor operation resulted in his invention of the compare-and-swap instruction (mnemonic chosen because CAS are charlie's initials). initial forey with pok and 370 architecture owners were met with brick wall resistance because the pok favorite son operating system people claimed that the test-and-set instruction (from 360 days) were more than sufficient for all multiprocessor support. The challenge was in order to justify comapre-and-swap instruction was a non-multiprocessor use had to be defined/invented. The result was the multi-threaded use description (whether or not the environment was multiprocessor) that current shows up in appendix section in principles of operation. misc. posts mentioning multiprocessor and/or compare-and-swap instruction http://www.garlic.com/~lynn/subtopic.html#smp somewhat related to the original thread subject ... when i first got a copy of cp67 at the university as an undergraduate ... when virtual machine logged on ... the virtual address space "backing store" (for the virtual machine) were all initialized to a single, special "zeros" page on the cp67 ipl/boot volume. Each corresponding page table entry that pointed to the "zeros" page also had a flag that if the virtual page was ever modified/changed (after being fetched into real storage), it was to have a new (disk paging) backing location dynamically allocated. an early enhancement that i made to cp67 ... was to initialize freshly, created virtual storage with indication that on initial page fault, that instead of fetching the virtual page from some disk location ... that a real page was to be allocated and then simply cleared to zeros (i used a bxle loop with stm of ten registers that had been all cleared to zeros). The "recompute" flag still remained the same ... i.e. if virtual execution subsequently "modified" a zeros page ... it would have a new back disk page location dynamically allocated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
