shmuel+...@patriot.net (Shmuel Metz , Seymour J.) writes: > That's not the Multics model. The Multic model is that segment numbers > are dynamically assigned as needed, and that in general two processes > will use different numbers for the same segment. IBM had something > similar in TSS, but abandoned it.
some of the people from CTSS went to the 5th flr and did Project Mac multics. other of the people went to the science center on the 4th flr and did virtual machines, online computing, the internal network ... GML was invented at the science center in 1969, as well as lots of performance monitoring and modeling stuff ... some of which evolves into capacity planning ... misc. past posts mentioning 545 tech sq http://www.garlic.com/~lynn/subtopic.html#545tech supposedly 360/67 (360/65 with virtual memory) was to be ibm's candidate for project mac ... but ge won the bid instead ... and multics was done on ge645. melinda's history has lots of details ... can be found here: http://www.leeandmelindavarian.com/Melinda/ tss/360 was then going to the official operating system ... including virtual memory and "single-level-store" (storage mapped as virtual memory ... 360/67 had both 24bit and 32bit virtual addressing modes). at one point tss/360 is claimed to have something like 1200 people at the time the science people had 12 people on cp40/cms (before being able to get 360/67, they modify 360/40 with virtual memory hardwre, later when they were able to get 360/67, cp40/cms morphs into cp67/cms ... and later into vm370/cms). old user group presentationon cp40 http://www.garlic.com/~lynn/cp40seas1982.txt tss/360 & 360/67 were sold to lots of univ. ... but TSS/360 never quite became product ... and so many systems ran as 360/65 as os/360 for most of the time. as undergraduate in the 60s, there was work on both tss/360 and cp67 on the weekends. we did one fortran edit, compile, and execute simulated user benchmark. tss/360 running the script with four simulated users got worse throughput and interactive response than cp67/cms with 35 simulated users (on the same hardware). the Future System project in the early 70s was going to also be "single-level-store" based ... from tss/360, multics, etc. recent reference to future system: http://www.garlic.com/~lynn/2013h.html#44 Why does IBM keep saying things like this: at the same time I was at the science center and did paged-mapped filesystem for cms (somewhat in competition with multics on the floor above). Having observed a lot of the tss/360 problems ... I did an implementation that avoided many of the problems (and would periodically ridicule the FS ... claiming what I already had running was better). it never made it as part of release product ... in part because of the bad rep that single-level-store got from the FS effort ... even though I could show 3times the throughput/efficiency compared to standard CMS filesystem (both CDF & EDF) for moderate filesystem workload. some past posts http://www.garlic.com/~lynn/submain.html#mmap part of it was to have same exact shared segments at different virtual addresses in different virtual address spaces ... which also wasn't released. A small piece of the shared segment (w/o filesystem stsuff and supporting concurrent shared images at different virtual addresses) ... was released as DCSS in vm370 release 3. some old email from the period http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 one of the hardest problems was that CMS borrowed a lot of stuff from os/360 and there was enormous problem with os/360 relocatable adcons (which are swizzled to absolute address after being loaded for execution). I needed *real* relocatable adcons ... both at load time as well at execution time. This was one thing supported by tss/360. some past posts discussing constant battle that i had with os/360 relocatable adcons http://www.garlic.com/~lynn/submain.html#adcon note that folklore is that after FS failure, some of the people retreated to Rochester and did single-level-store for S/38 ... note however, the S/38 wasn't into performance throughput ... so the single-level-store performance issues weren't an issue. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
