using 3390 mod9s 3191

Ron and Jenny Hawkins

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

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

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.

misc. past posts mentioning the 1655s that were made available internally please instruction count instead of timer Was Re: Yamhill Was Re: Yamhill is an MVT ABEND 422? Something About DASD