norman.hollan...@desertwiz.biz (Norman.Hollander) writes: > Track size. We actually used to use a 2305 "drum" definition for VIO. > But if you genned 1 dummy address, you had to gen all 8. Made for a > larger IO-gen. So we would go for the next best tracksize of the > 2314. So- how many 4K pages fit into a track without wasting too much > of it? Plus the 2314 was small, so quick sorts in VIO might be > possible, but it prevented sorting a kabillion records. I'm pretty > sure 2305 support was removed a long time ago, so you couldn't define > it today. Probably true for the 2311/2314/2319. Last time I went > through IODF, a fake 3390 (address DEFF) was defined as the only VIO > capable device. With all the various Sort and Memory exits today, it's > probably just a good history lesson. Oh- way back in the 70s, a > company named Ampex (IIRC) made look alike (aka cheaper) memory and > Disk storage. Think their mountable disk was the 3314. OK- discuss > further...
design point for 3090 needed lot more memory than originally planned ... combination of software bloat and 3880 disk controller was much slower than originally predicted (which then required doubling number of channels, which required an additional TCM, joke was 3090 product was going to charge the disk division for the manufacturing cost of the additional TCM). Physical packaging problem for the additional memory required longer distance that exceeded the original latency specs ... so they invented expanded store ... with a very wide bus and software interface that could quickly move 4k page between processor memory and expanded store (but physically it was the same memory technology). Slightly before that, one of the vendors started producing simulated 2305 "electronic paging device" ... using electronic memory ... and IBM bought a whole load of them for internal use (internal designation was "1655"). The question was asked why couldn't IBM produce such an electronic disk ... and the answer was every memory chip IBM was producing was already being sold as memory (and/or expanded store) ... which had a lot higher profit margin than electronic disk. The "1655" vendor did point out that they were using memory chips that had failed tests required for processor memory ... but could still be used in simulated electronic disk (with disk controller electronics being able to compensate for various memory issues). The 3090 expanded store bus was than also used for supercomputer HIPPI 100mbyte/sec RAID disks. Standard 3090 channels couldn't remotely come close to handling HIPPI 100mbyte/sec ... so they came up with this hack to cut HIPPI interface into side of the expanded store bus ... and then they used reserved expanded store bus addressed to implement peek/poke kind of I/O semantics (to initiate HIPPI read/write I/O operations). I/O trivia: 1980 I was con'ed into doing channel extender support for IBM STL lab that was moving 300 from the IMS group to off-site bldg .... with service back into the STL datacenter. They had tried "remote" 3270 and found it totally unacceptable (comapare to the direct channel attached 3270 human factors that they were use to). The channel extender support put a channel emulator at off-site bldg with direct channel attached 3270 controllers, Channel programs were down loaded to the remote channel emulator ... which went a long way to eliminating the enormous overhead & latency of chnanel interface protocol chatter. The vendor then wanted to get approval from IBM to release my support, but there was a group in POK playing with some serial stuff that objected (because they were afraid if my stuff was released, it would make it harder to get their stuff released). Then in 1988, I was asked to help LLNL get some serial stuff they were playing with standardized (the standard would include remote i/o program download&execution to eliminate significant I/O program protocol chatter latency). This quickly becomes fibre-channel standard (originally supporting 1gbit/sec concurrent transfer in both directions). Then in 1990, the POK group gets their stuff released as ESCON when it is already obsolete. Then some POK people get involved in fibre-channel standard and define a heavy-weight protocol that drastically reduces the native throughput ... that is eventually released as FICON. Latest published "peak I/O" throughput was z196 using 104 FICON to get 2M IOPS. At about the same time a (single) fibre-channel was announced for E5-2600 blade claiming over million IOPS (two such fibre-channel having higher native throughput than 104 FICON running over 104 fibre-channel). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
