The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well.
patrick.falco...@verizon.net (Patrick Falcone) writes: > Correction they were 3081K 32's, one of the other posts jolted my > memory back into focus. Sorry for the drift. re: http://www.garlic.com/~lynn/2009g.html#66 Mainframe articles http://www.garlic.com/~lynn/2009g.html#67 Mainframe articles http://www.garlic.com/~lynn/2009g.html#68 IT Infrastructure Slideshow: The IBM Mainframe: 50 Years of Big Iron Innovation http://www.garlic.com/~lynn/2009g.html#70 Mainframe articles 3033 and 3081 in 370 mode were 24bit (16mbyte) addressing (real & virtual). issue was that disk thruputs weren't keeping pace with the rest of the system infrastructure ... i.e. processing & memory performance was increasing faster than disk performance. I had started pontificating in the 70s about the growing performance mismatch. what was happening was that increasing amounts of electronic storage (starting with real memory on the processor and then disk controller cache) was being used to cache disk information to compensate for the increasing disk thruput bottleneck. this is referencing comparing 360/67 to 3081k (separated by almost 15 yrs) running similar (virtual machine) CMS workload ... and claiming that relative system disk thruput had declined by a factor of ten times in the period. http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door some disk division executives took some offense with the claims and assigned the division performance group to refute my statements. after a few weeks, the group came back and effectively said that I had slightly understated the problem. That study eventually turned into a SHARE (63) presentation (B874) recommending how to configure/manage disks to improve system thruput. old post with reference: http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?) in any case, it was starting to become a real issue in the 3033 time-frame. it was possible to configure vm clusters of 4341s with higher aggregate thruput than 3033 at a lower cost. furthermore, each 4341 could have 16mbytes (and six i/o channels) compared to 3033's with 16mbytes (and 16 i/o channels). to somewhat address/compensate ... there was a hardware hack to have 3033 configured with 32mbytes of real storage (even though the processor was restricted to both real & virtual 16mbytes addressing). the hack involved 1) using (31bit) IDALs to being able to do I/O for real addresses above 16mbyte "line" (most importantly being able to read/write pages above the line) 2) page table entry was defined as 16bits, 12bit page number (4096 4096byte pages or 16mbytes), 2 defined bits and 2 undefined bits. the two undefined bits were re-allocated for prepending to the page number allowing up to 16384 4096byte pages or up to 64mbytes real storage, but only max. of 16mbytes per virtual address space). ... lots of things would require virtual pages, that were above the (16mbyte) line to be brought into the first 16mbytes of real storage. initially there was a definition where the software would write the (above the line) virtual page out to disk and then read it back into real storage (below the line). I generated some example code that involved special virtual address space and fiddling the real page numbers in two page table entries ... allowing 4k of real storage above the line to be "copied/moved" to 4k of real storage below the line (avoiding having to write to disk and read back in). this hack (for real storage >16mbytes) was carried forward for 3081s operating in 370 (24bit, 16mbyte) addressing mode. a few past posts discussing (3033/3081) >16mbyte http://www.garlic.com/~lynn/2004o.html#59 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine http://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370 http://www.garlic.com/~lynn/2006w.html#23 Multiple mappings http://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007b.html#34 Just another example of mainframe costs http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!) http://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical http://www.garlic.com/~lynn/2009d.html#48 Mainframe Hall of Fame: 17 New Members Added and some number of past posts mentioning vm/4341 clusters http://www.garlic.com/~lynn/2001m.html#15 departmental servers http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory? http://www.garlic.com/~lynn/2005n.html#11 Code density and performance? http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3 http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries? http://www.garlic.com/~lynn/2006b.html#39 another blast from the past http://www.garlic.com/~lynn/2006i.html#41 virtual memory http://www.garlic.com/~lynn/2006l.html#2 virtual memory http://www.garlic.com/~lynn/2006l.html#4 Google Architecture http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?) http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy? http://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders? http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders? http://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370 http://www.garlic.com/~lynn/2007f.html#44 Is computer history taught now? http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!) http://www.garlic.com/~lynn/2007j.html#71 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007n.html#20 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series http://www.garlic.com/~lynn/2007o.html#56 360/30 memory http://www.garlic.com/~lynn/2007o.html#72 FICON tape drive? http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2008b.html#8 on-demand computing http://www.garlic.com/~lynn/2008d.html#64 Interesting ibm about the myths of the Mainframe http://www.garlic.com/~lynn/2008d.html#71 Interesting ibm about the myths of the Mainframe http://www.garlic.com/~lynn/2008e.html#73 Convergent Technologies vs Sun http://www.garlic.com/~lynn/2008k.html#60 recent mentions of 40+ yr old technology http://www.garlic.com/~lynn/2008o.html#57 Virtual http://www.garlic.com/~lynn/2009d.html#48 Mainframe Hall of Fame: 17 New Members Added http://www.garlic.com/~lynn/2009d.html#54 mainframe performance http://www.garlic.com/~lynn/2009e.html#45 Mainframe Hall of Fame: 17 New Members Added http://www.garlic.com/~lynn/2009f.html#50 what IBM 360/370/etc. model was their best seller? -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
