MCTS 2990

GMR (gm research) was one of the major tss-360 users ... for years after it was decommited. 360-67 had support for virtual 24-bit and 32-bit addressing modes ... and GMR made big deal about having application that laid out everything in flat, one-level store allowed by tss-360 32-bit support (straight-foward page-mapped stuff stuff w-o having to resort to typical filesystem semantics in the application).

when virtual memory was announced for 370 ... only 24-bit virtual addressing was available ... and there was a port of tss-360 to tss-370 (although w-o any 32-bit virtual addressing support).

when 370-xa support was announced for 3081 in the early 80s, it only had provision for 31-bit virtual addressing ... not the 32-bit virtual addressing that had been available on 360-67.

one of the major users of tss-370 was at&t ... a custom, stripped down version of the tss-370 kernel was done called sss-370 ... which had unix api interface layered on top. I spent some time in the 80s looking at doing a merge of sss-370 underlying kernel with virtual machine support.

someplace I have some old detailed analysis comparing sss-370 stripped down kernel with vm-370 kernel from the era. part of the issue was that since tss-370{360} had been decommited, it only had a very small group of dedicated professionals supporting the kernel. The issue with vm-370 was that it became more and more popular, there were lots of people with traditional operating system backgrounds buttigned to work on it. As a result, the original vm-370 kernel philosiphy was severely compromised with lots of stuff being dropped into the kernel layer that should have been better done in another way (with vm-370 kernel starting to look more like the original bloated tss-360 kernel and sss-360 starting to look more like the original cp-67 kernel).

reference to multics being one-level store ... and large multics application at gmr ... and listed some of the other systems that had implemented one-level store (including tss-360)

note while the above claimed that the listed systems had picked up one-level store from multics, tss-360 and multics were going on concurrently. for lots more history of the period (ctss, tss-360, project mac, multics, science center, virtual machines, etc) see melinda's historical paper

various other multics references talk about multics and one-level store being used at gm long after tss-360 was gone ... this references multics GM (same GM?) shutdown in the fall of 98:

search engine even coughed up an old posting of mine about GM claiming enormous productivity increases for their programmers developing 32bit (one-level store) applications

this paper mentions that GM had developed the first operating system in the mid-50s and the idea had caught IBM's attention (which led to IBM investing in the new concept)

umich also had written MTS for 360-67 that supported 24-bit virtual addressing

the series of MTS historical references that used to be here ... seemed to have gone 404

minor drift from long ago and far away ... (making references to a traditional low-level unix kernel was even drastically more simpler than sss-370).

TO: wheeler at sjrlvm1 Dear Lynn, I got the full scoop on the Amdahl UNIX benchmark. I called in a marker on a UNIX system type at Bell Labs. (I had help him prove that system crashes were due to a bug in the Amdahl hardware.)

The benchmark was a full system test on the new UTS software. It is unfortunate that the number 1.8 got out. Bell ran several benckmarks. The best of them was 1.8. The overall average was around 1.5. This was a comparason of UTS to SSS-370 on the same hardware. I beleive it was a 3081 running as a uniprocessor. Remember, UTS does not run MP.

The 5860 uniprocessor runs at about 80% of the combined 3081 multi- processors. Since his software does not run MP, if you compare his hardware-software to the IBM hardware-software, the throughput difference is 1.25 (1.5 times .80).

Bell claims not to know when Amdahl will put MP support in UTS. Bell says that they have no idea what it will cost (in performance) to implement MP (semaphores, etc.)

For the current set of UNIX benchmarks (all jobs fit in memory, no paging, no contention, etc.), it does not do much good to have a high-powered supervisor. The current SSS-370 systems at Bell do almost no paging (over 90% of I-O is data access) and almost no scehuling (all jobs currently active fit in memory). Until the typical UNIX workload changes, a complicated high-powered supervior has too much overhead.

--