🚀 go-pugleaf

Jay Maynard <jmaynard@thebrain.conmicro.cx> writes:
> Not quite...there were 13 customers supported for TSS/370, some for
> quite some time. IBM supported it on an RPQ basis for them until
> 1987. I know of at least one that liked TSS so much that they bought
> Amdahl processors for some time in retaliation for TSS getting
> dropped.
>
> TSS definitely had some advanced algorithms, and was designed for
> the very top end of the line - as in, off the top of the 360's
> capabilities. It definitely wanted a multiprocessor box and lots of
> real memory. Once you got to a high-end 370, it supposedly ran quite
> well.

melinda's account goes into a lot more detail ... 
http://pucc.princeton.edu/~melinda/
but during tss/360's heyday in the 60s ... cambridge had something
like 12 people working on cp/67 and cms (as well as coming up with
GML, editors, interacitve computing, GML ... which begate SGML, HTML,
XML, etc). Mohansic had something like 1200 people working on tss/360.

during this period, there was a joke about IBM rewarding people for
development disasters ... because people tended to get promoted and
paid based on the number of people reporting to them. If you were able
to get the job done with 12 people ... you got paid based on having 12
people reporting to you. If your development project ran into extreme
disaster and had to baloon up to a bloated 1200 people ... then you
got more promotions, prestige and money. an executive's goal became
not to have a really good development project ... but to have one that
was a true disaster ... so they could justify a hundred times as many
people.

tss/360 had concept of virtual memory and one-level store ... but
almost not concept of performance techniques and dynanic adaptive
anything. besides tss/360 horribly long pathlengths there were some
static things that they just didn't stop and think about. CMS used a
lot of compilers and other applications from os/360 which were
optimized for memory constrained environment ... i.e. overlays of
50kbytes ot 100kbytes with efficient transistion from one overlay to
the next. TSS/360 would just lay such stuff out in virtual memory and
do simple 4k, single page fault at a time. So under CMS, it would
attempt to bring in the 50k-100k piece of the compiler ... and then at
change of phase bring in the next 50k-100k segment (attempting to do
as a single I/O each time). TSS/360 might have it all as a 1mbyte, and
have to individual page fault, each individual 256 4k page. When
running on 512kbyte real machine ... it might have to page fault
various of the 256 4k pages multiple times.

In any case, at about the time CP67/CMS was supporting 30 users doing
fortran program edit, compile and test ... TSS/360 on the same
hardware, would be supporting 4 users doing same fortran program edit,
compile and test with worse response.

A typical configuration might be 768kbyte real machine, 2301 (fixed
head) paging drum, 8-16 2314 packs for system, paging, application.  A
simple example of not having dynamic adaptive was that when user hit
interactive edit return on 2741 (after having been think-time idle),
TSS would attempt to pre-fetch the appropriate pages into real storage
and then write them out to the 2301 (effectively pre-staging them from
2314 to 2301 by dragging them thru real memory). When the edit
transaction was complete and the user was idle/thinking again ...  TSS
would stage all the pages back to 2314 from 2301 by pulling them thru
real memory. TSS would always do this ... even if there was only a
single user on the system and there was absolutely no contention for
either real memory or the 2301.

So there is the folk tale about when tss/360 was decommitted and the
group supposedly dropped from 1200 people down to 20 or so
people. Now, instead of having a couple dozen people assigned to every
module, a single person now had responsibility for a large number of
different modules. Supposedly, one such person discovered that the
original TSS/360 specs required that the TSS/360 scheduler be called
whenever anything happened ... on the off-chance that a task state had
changed.  The resulting implementation had every module in the system
calling the scheduler. The scenario was that on a kernel call ... the
processing might involve sequential execution thru several dozen
kernel modules. Supposedly after decommitment (with multiple modules
per person as opposed to multiple people per module), somebody
realized that it was only necessary to call the scheduler once, at the
end of the kernel call processing sequence ... and not in every
module. Supposedly, the resulting change to single scheduler call took
a million instructions out of the avg. kernel call pathlength.

There is this joke, that even with CMS having more compact real
storage requirements and much more efficient transitions between
program execution phases ... so that the number of page faults was
drastically reduced ... I had done cp/67 pathlength optimization so
that the total instructions to 1) take page fault, 2) execute page
replacement algorithm, 3) perform page write for the replaced page, 4)
task switch to different process during page fault processing, 5)
perform page read for the replaced page and 6) task switch back to the
faulting process was on the order of 500-600 instructions
(total). TSS/370 may have eventually gotten their pathlength down to
1k-2k instructions (and VS2 was like 10k instructions).  Furthermore,
the science center was later able to show that the page replacement
algorithm that I had invented not only had drastically shorter
pathlength ... but also typically made significantly better
replacement choices (some cases 1/10th the total pathlength for a ten
times better choice).

lots of old tss postings:
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#1 pathlengths
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#48 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
http://www.garlic.com/~lynn/2001l.html#7 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question
http://www.garlic.com/~lynn/2001l.html#11 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#18 mainframe question
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2001n.html#89 TSS/360
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002d.html#23 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002j.html#27 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#57 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003d.html#58 POWER hashes vs tree
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#41 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
http://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
http://www.garlic.com/~lynn/2004.html#4 TSS/370 source archive now available
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory


-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/