The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Tom Schmidt) writes: > When I lived in POK I was told that a part of the reason for extended > storage also had to do with its lack of requirement for storage protect key > arrays. The extended storage memory was then allowed to be more like the > memory of the competitors in terms of cost, structure & simplicity. (By > the early 1990s the competition was considered to be HP, not Amdahl nor > HDS). say 6bits of storage key per 4k bytes is lost in the noise? (2k storage keys as well as 2k virtual pages having been dropped around 3081 xa time-frame) ... if you wanted to worry about something ... there was 16bit ecc for every 64bit double word (or 2bits per 8bit byte ... as opposed to parity bit per 8bit byte) ... optimizations were trying to get failure coverage (better than simple 1bit/byte parity) with less than 80bits (for 64bit of data) ... like 78bits, 72bits, etc ... press release on ecc from 1998 http://www-03.ibm.com/press/us/en/pressrelease/2631.wss another discussion of memory ecc http://www.research.ibm.com/journal/rd/435/spainhower.pdf in response to off-list comment about 360 model storage sizes ... see this reference: http://www.beagle-ears.com/lars/engineer/comphist/model360.htm note that 1mbyte and 2mbyte, IBM "LCS" 2361 was offered ... but I remember a number of installations having 8mbyte "Ampex" LCS. the claim was that 3090 extended store memory chips was effectively the same as regular memory chips ... because ibm had really good memory yield. however, there was a vendor around 1980 that had some problems with its memory chip yield involving various kinds of failures that made the chips unuseable for normal processor fetch/store (memory). so a bunch of these "failed" memory chips were used to build 2305 (fixed head disk) clone ... and a fairly large number of them (maybe all that the vendor could produce) were obtained for internal use ... using a "model" number of 1655 for use as dedicated paging devices on internal VM timesharing systems. The claim was that they were able to engineer compensation (for various chip problems) at 4k block transfer boundary that wouldn't be practical if you were doing standard processor fetch/store. some recent posts mentioning the 1655 2305-clone paging devices: http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory? http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s http://www.garlic.com/~lynn/2006k.html#57 virtual memory for other drift ... there was a lot of modeling for 3090 balanced speeds&feeds ... part of it was having sufficient electronic memory to keep the processor busy (which then led to the extended store stuff) part of the issue was using electronic memory to compensate for disk thruput. starting in the late 70s, i was making statements about disk relative system thruput had declined by an order of magnitude over a period of years. the disk division assigned the performance and modeling group to refute the statement. after a period of several weeks, they came back and mentioned that i had actually slightly understated the problem ... the analysis was then turned around into a SHARE presentation on optimizing disk thruput (i.e. leveraging strengths and compensating for weaknesses). misc. posting referencing that share presentation http://www.garlic.com/~lynn/2001l.html#46 MVS History (all parts) http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s one of the issues that cropped up (somewhat unexpectantly) was the significant increase in 3880 (disk controller) channel busy. the 3090 channel configuration had somewhat been modeled assuming 3830 control unit channel busy. the 3830 had a high performance horizontal microcode engine. for the 3880, they went to a separate processing for the data path (enabling supporting 3mbyte/sec and then 4.5mbyte transfers), but a much slower vertical microprogrammed engine for control commands. this slower processor significantly increased channel busy when processing channel controls/commands (compared to 3830). a recent post discussion some of the problems that cropped up during 3880 development (these showed up before first customer ship and allowed some work on improvement) http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy? however, there was still a fundamental issue that 3880 controller increased channel busy time per operation ... greater than had been anticipated. in order to get back to balanced speeds&feeds for 3090 ... the number of 3090 channels would have to be increased (to compensate for the increased 3880 channel busy overhead). now, it was possible to build a 3090 with relatively few TCMs. the requirement (because of increased 3880 channel busy) to increase the number of channels resulted in requiring an additional TCM for 3090 build (for the additional channels) ... which wasn't an insignificant increase in manufacturing cost. at one point there was a suggestion (from pok) that the cost of the one additional TCM for every 3090 sold ... should be taken from sanjose's bottom line (as opposed to showing up against POK's bottom line). the overall situation might be attributed to the after effects from the failure of FS http://www.garlic.com/~lynn/subtopic.html#futuresys a big driving factor in FS was countermeasure from clone/plug compatible controllers ... some collected postings having been involved in greating plug compatible controller as an undergraduate http://www.garlic.com/~lynn/subtopic.html#360pcm however, from this article on FS (by one of the ibm executives involved) http://www.ecole.org/Crisis_and_change_1995_1.htm from above: IBM tried to react by launching a major project called the 'Future System' (FS) in the early 1970's. The idea was to get so far ahead that the competition would never be able to keep up, and to have such a high level of integration that it would be impossible for competitors to follow a compatible niche strategy. However, the project failed because the objectives were too ambitious for the available technology. Many of the ideas that were developed were nevertheless adapted for later generations. Once IBM had acknowledged this failure, it launched its 'box strategy', which called for competitiveness with all the different types of compatible sub-systems. But this proved to be difficult because of IBM's cost structure and its R&D spending, and the strategy only resulted in a partial narrowing of the price gap between IBM and its rivals. ... snip ... i.e. the 3880 "box strategy" might be construed as sub-optimal from an overall system perspective. for other drift ... recent postings about san jose disk http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#18 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#21 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#30 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#31 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006r.html#33 50th Anniversary of invention of disk drives ---------------------------------------------------------------------- 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
