Ed Gould wrote: > I think the 2314 was the original suggestion by IBM. 2314 (29 mbytes) and 2301 (paging drum, 4mbytes) were contemporaries on 360/67 (early 360/67s tended to have 2311 7mbytes before 2314s were available). there were two drum models, 2303 and 2301. the 2303 read/wrote single head. the 2301 was nearly identical but read/wrote four heads in parallel (for four times the data transfer rate).
table of some old capacity http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives the above gives both nominal access/sec/drive as well as normalizing the access rate by capacity ... giving access/sec/mbyte ... i.e. a 3380 limited to just 40mbyte gives approx. the same access/sec/mbyte as fully loaded 2314. "early ibm disk history" (from wikipedia) http://en.wikipedia.org/wiki/IBM_350 also, if any remembers additional code names, they may be able to help complete this table http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts) 370s (especially after virtual memory was announced) tended to have 3330-1 (100mbytes) and 2305 (12mbytes, fixed head disk). there were actually two 2305 models; one with 12mbytes and one with 6mbytes. the 6mbyte model had same number of heads as 12mbyte model but "ganged" and offset 180degrees (and 1/2 the tracks). it only read/wrote a single head ... but chose the first head that encountered the desired record (and therefor had 1/2 the avg. rotational delay). around 1980, a lot of internal sites got "1655". these were emulated 2305s built by a memory chip vendor that used memory chips that had failed some standard memory chip test. There were enuf useable bits in the chip that the "1655" controller circuitry was able to compensate for various failures (at least in i/o transfer operations). the 3350 had a couple cylinders that could have a fixed-head option. in the late 70s, i was trying to get a feature added that would provide a separate "exposure" address to any fixed-head region (to avoid having fixed-head i/o blocked by 3350 arm motion i/o). this ran into politics with a POK group that was planning something called vulcan ... basically something similar to (later) 1655 ... or imagine something like 3090 expanded store but with i/o semantics. they felt that such an enhanced 3350 fixed-head option for paging would compete with vulcan (vulcan was canceled before announce). the first kernel to run virtual memory on 370 was a modified version of cp67. there was a joint project between endicott and cambridge http://www.garlic.com/~lynn/subtopic.html#545tech to implement 370 virtual machines (which were similar to 360/67 but differed in the virtual memory hardware architecture). the basic csc/vm production cp67 (running on cambridge's 360/67) was "cp67l". the joint endicott/cambridge project modifications to provide 370 virtual machines was "cp67h". the cp67h system rarely ran on the real hardware. the issue was that the cambridge machine also provided various kinds of time-sharing system to people at educational institutions in the boston area (had mit, bu, harvard, etc students). 370 virtual memory hadn't been announced and there was a real security issue if the cp67h system ran on the real hardware, 370 virtual memory details might leak. as a result cp67h tended to only run in a 360/67 virtual machine under cp67l production system. once cp67h was operational, then there were modifications to create a cp67 that ran on 370 virtual memory called "cp67i". a year before the first 145 engineering model with virtual memory hardware, cp67i was regularly running in 370 virtual machines under cp67h (which was running in 360/67 virtual machines under cp67l). there is old story about when the endicott engineers felt that they finally had virtual memory hardware ready to test and there was a trip to endicott with a copy of cp67i. the first boot failed. after a little diagnoses, it turned out that the engineers had reversed two of the new "B2xx" op-codes. the kernel was quickly patched to correspond to the (incorrect) hardware and the system successfully booted. after that there was period when most of the internal 370s (with virtual memory support) ran with cp67i (both before and after 370 virtual memory was announced). early on, there were three disk engineers that came out from san jose and added the support for 3330 and 2305 ... including supporting RPS (lots of early 145s had been running with 2314s). cp67i with 3330 & 2305 support was frequently referred to as cp67sj. old "cp67i" stories http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse http://www.garlic.com/~lynn/2004b.html#31 determining memory size http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap ! http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas? http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ? http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3 the early VS2 prototype started out with a version of MVT with virtual memory software support hacked onto the side incorporating a cribbed version of CP67's CCWTRANS to do the virtual->real channel program translation. http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory past posts mentioning the vs2 effort starting with CCWTRANS http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love? http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...] http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline? http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline? http://www.garlic.com/~lynn/2001l.html#36 History http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems http://www.garlic.com/~lynn/2002p.html#49 Linux paging http://www.garlic.com/~lynn/2002p.html#51 Linux paging http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3 http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers adding virtual memory hardware to 370/165 was holding up the whole 370 virtual memory announcement. there was a resolution meeting where the 165 engineers proposed dropping some of the 370 virtual memory features, which would cut six months off their effort. when this was accepted, all existing implementations on other models needed the dropped features deleted. past posts mentioning posts mentioning difficulty of adding virtual memory to 370/165. http://www.garlic.com/~lynn/99.html#7 IBM S/360 http://www.garlic.com/~lynn/99.html#204 Core (word usage) was anti-equipment etc http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit? http://www.garlic.com/~lynn/2001c.html#7 LINUS for S/390 http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd) http://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes? http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs http://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers? http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment http://www.garlic.com/~lynn/2006.html#13 VM maclib reference -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
