[email protected] (Shmuel Metz , Seymour J.) writes: > IBM issued sevaral releases of TSS/360 and even had a PRPQ for TSS/370 > before they cancelled it. TSS performance was considerably better by > then.
re: http://www.garlic.com/~lynn/2012o.html#31 Regarding Time Sharing http://www.garlic.com/~lynn/2012o.html#32 Regarding Time Sharing 1968 ... i did simulated 35 user cp67/cms for fortran program edit, compile, link and execute ... that had better response and throughput than simulated four user tss/360 for same fortran program, edit, compile, link and execute ... on the same exact 360/67 hardware. at the time of the test, cp67 had many of the pathlength enhancements mentioned in previous posts ... but not the rewrite of the virtual memory and my dynamic adaptive resource manager. tss/370 had number of special bids, one was AT&T to do a stripped down TSS/370 kernel (SSUP) that had unix layered ontop. Amdahl was in marketing UTS ... direct unix port ... mostly running in vm370 virtual machine. Eventually IBM also did port of UCLA LOCUS (unix work-alike) ... also running in vm370 virtual machine ... announced as aix/370 (coupled with aix/386 ... LOCUS supported distributed filesystem as well as processing ... even migrating processes between 386 and 370 with different binaries). Issue in the period was field maintenanced required EREP and error recovery. At the time, to add mainframe EREP and error recovery to unix kernel was several times larger effort than just the straight forward unix port to mainframe. one of the early jokes about tss/360 ("official" timesharing) was that it had approx. 1200 people working on it at time when the science center had approx 12 people working on cp67/cms. by the mid-70s, after the tss/360 decommit and before pok convinced corporate to kill-off vm370 and transfer all of the people to POK to work on mvs/xa (mentioned before that endicott manage to save the product mission, but had to reconstite a group from scartch) ... the tss/370 group had 20 people and the vm/370 group (followon to cp67) had maybe 300 people ... aka the performance of a system is inversely proportional to the number of people working on it. spring 1985, i was involved in comparison study of tss and vm/sp kernels; part of that analysis (vm/sp had gotten grossly bloated by that time): TSS VM/SP modules 109 260 lines of assembler code 51k 232k misc. posts posts mentioning tss/vmsp comparison study: http://www.garlic.com/~lynn/2001m.html#53 TSS/360 http://www.garlic.com/~lynn/2006e.html#33 MCTS http://www.garlic.com/~lynn/2010e.html#17 Senior Java Developer vs. MVS Systems Programmer (warning: Conley rant) misc. old email mentioning tss/unix http://www.garlic.com/~lynn/2006b.html#email800310 http://www.garlic.com/~lynn/2006t.html#email800327 http://www.garlic.com/~lynn/2007e.html#email800404 http://www.garlic.com/~lynn/2006f.html#email800404 http://www.garlic.com/~lynn/2007b.html#email800408 http://www.garlic.com/~lynn/2006e.html#email840109 note: native tss/360 had paged-mapped filesystem ... pagetables could be setup to point directly at executable image on disk ... and could be page directly in and executed ... even relocatable code that could concurrently reside in different virtual address spaces at different virtual addresses. the tss/360 relocatable executable format was quite a bit different thatn os/360 relocatble executable format. In os/360 relocable executable format, the file had to be preloaded into memory and all address constants swizzled to absolute value (representing their loaded location). tss/360 executable address constants were truely relocatable ... i.e. the address constants in the executable image didn't require any fiddling ... the executable image could be mapped to any virtual address and everything worked. the os/360 convention caused enormous problems for me when i did page mapped filesystem for cp67/cms. cms adopted lots of applications, compilers, loaders, etc. from os/360 ... which required that relocatable address constants be swizzled to absolute address after loading and before execution. for truely high-performance operation ... I had to do a lot of application fiddling to make the relocatable address constants more like tss/360. I had also seen lots of (other) things that tss/360 had done wrong in the page mapped implementation ... which i avoided in my cp67/cms implementation. Then Future System effectively did a similar rote page mapped filesystem desgin with all the other tss/360 performance shortcomings. It was one of the things that I would periodically ridicule the FS group about ... believing what I already had running was better than what they were doing high level specs. on. ... misc. past posts mentioning having done cp67/cms paged-mapped filesystem http://www.garlic.com/~lynn/submain.html#mmap misc. past posts mentioning horrors having to deal with os/360 relocable address constants http://www.garlic.com/~lynn/submain.html#adcon -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
