Ron and Jenny Hawkins wrote:
I think that this is too true. Two observations support this:
1) The growing market for Solid State Disk (SSD) prior to the 3880-13 - HDS,
EMC and STK (Amdahl?) were all shipping these boxes, and AFAIK at enormous
margins.
2) The quick decline in SSD sales after the 3880-13, followed by a fatal
blow with the introduction of the 3990-3 (and PCM equivalents).
there were also the electronic memory "1655" that emulated 2305, several
hundred were made available for internal installations.
i was somewhat caught by the explanation for the vendor's 1655s.
supposedly the internal memory manufacturing process had been perfected
so that there was very high yield (that and/or the internal mental
process was that any chips that failed test were automatically
scrapped). the vendor doing the 1655 had quite a bit of memory chips
that failed test. however, the requirements for electronic disk
operation was totally different than the requirements for processor
memory operation. glitches that couldn't be tolerated in processor
memory could be used in electronic disk application where the embedded
device controller could compensate for numerous types of memory chip
glitches ... and take advantage of chips that were otherwise heading for
scrap.
another thing that happened in the 80s was the market uptake of
relational databases. the original relational/sql was system/r that had
been done in the 70s at sjr. misc. past posts on relational, sql,
system/r, etc
http://www.garlic.com/~lynn/subtopic.html#systemr
during this period there were ongoing arguments between the "60s"
database people at Santa Teresa (bldg. 90) and the system/r people at
sjr (bldg. 28).
sort of the summary was STL forces claimed that relational substantially
increased the disk space requirements (indexes typically doubled the
required physical disk space) and significantly increased the i/o
(working the way thru indexes to get to a specific record). The
relational forces claimed that exposing record pointers as database
abstraction significantly increased the people manual effort in dealing
with databases. the relational abstraction eliminated people having to
deal directly with record pointer constructs ... and significantly
reduced people effort for managing and operating a database.
by the early 80s, hardware was becoming significantly less expensive,
people were becoming more expensive (and both electronic memory and disk
space was becoming significantly more plentiful). Inexpensive, plentiful
disk space muted the argument about doubling disk space for the
relational indexes (trade-off between hardware cost and people cost).
Furthermore, increases in electronic storage allowed significant amount
of relational indexes to be cached ... mitigating the I/O performance
penalty for using indexes vis-a-vis direct record pointers (this was
independent of additional electronic storage for general caching that
would improve overall thruput of all kinds of databases).
for some topic drift, reference in previous post about simulation and
modeling of various paging and caching ... discussed in this post
http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches
vs/repack was used by some number of corporate software products ... not
only in helping with program organization in the transition from real
memory operation to virtual memory operation .... but also just
generalized program optimization. One such operation that made use
vs/repack was the IMS organization in STL.
for additional drift ... when my wife did her stint in POK, in charge of
loosely-coupled architecture ... she had come up with "peer-coupled
shared data" architecture (sort of the foundation for lot of multi-CEC
operation and today's parallel sysplex). However, at the time, there was
a lot of corporate in-fighting. the communication division wanted
SNA-based communication not only for all terminal management but also
for all processor-to-processor operation. One of the few organizations
at the time that picked up on her architecture was the group doing IMS
hot-standby.
http://www.garlic.com/~lynn/subtopic.html#shareddata
misc. past posts mentioning the 1655s that were made available internally
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification
please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use
instruction count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities.
Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities.
Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck
is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew
Something About DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
----------------------------------------------------------------------
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
