[email protected] (Gerhard Postpischil) writes: > That doesn't sound right. Each TSO session runs in its own region, and > you need an additional TCAM or VTAM region to handle terminal I/O. A > machine with 4MB was considered large. So if you had three sessions of > that size, your machine probably wasn't doing much else. > > In our case we opted to run Wylbur, with dozens of users, which gave > as much higher productivity.
360/65 & 360/75 was one mbyte ... unless you got LCS add-on LCS mentioned here http://portal.acm.org/citation.cfm?id=1465599 and 2361 LCS mentioned here http://en.wikipedia.org/wiki/IBM_System/360 a 360/195 could have two mbytes ... but it was rather late in 360 time-frame ... and rather expensive to be used for TSO machine http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2195.html with 370 ... could get 2-3mbyte: http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PR370.html from above: Main core memories having capacities up to 2-million bytes for the Model 155 and 3-million for the Model 165. ... snip ... 370/168 in '72 with virtual memory standard ... had up to 8mbytes. http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH3168.html recent post in a.f.c. about virtual memory 360/67 (basically 360/65 with addition of virtual memory capality ... although multiprocessor version had a lot more changes more like 3081 than 360 & 370 multiprocessors) ... with some number of installations (especially univ) ordering the machine for use with tss/360. http://www.garlic.com/~lynn/2010j.html#67 Article says mainframe most cost-efficient platform with tss/360 running into number of problems ... some number of operations then did something of their own. the science center had started cp/40 on specially modified 360/40 with virtual memory ... which morphed into cp/67 when the center got an early 360/67. Michigan did MTS (using virtual memory). http://web.archive.org/web/20050212073808/www.itd.umich.edu/~doc/Digest/0596/feat01.html http://web.archive.org/web/20050212073808/www.itd.umich.edu/~doc/Digest/0596/feat02.html http://web.archive.org/web/20050212183905/www.itd.umich.edu/~doc/Digest/0596/feat03.html Stanford did Orvyl/Wylbur (and then Wylbur was available on vanilla os/360 platform) http://www.stanford.edu/~guertin/manuals/SPIDES.HTML#I.1.1.3.4 http://www.slac.stanford.edu/spires/explain/manuals/ORVMAN.HTML http://www.stanford.edu/dept/its/support/wylorv/ http://texteditors.org/cgi-bin/wiki.pl?Wylbur other places just used 360/67 as vanilla 360/65. Boeing Huntsville had a multi-processor 360/67 that they started out running as two 360/65 with os/360. it had been installed for some long running 2250 design applications ... which severely aggrevated MVT storage fragmentation. Boeing did do a hack for MVT-13 for using virtual memory (w/o any paging) as mechanism for re-org'ing memory into contiguous areas as work around to MVT storage fragmentation. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- 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
