[email protected] (R.S.) writes: > So, 12 years old FICON is simply obsolete and we should expect > something new? And don't tell me about FICON enhancements, ESCON was > enhanced as well! > So? Shall we expect wi-fi based channels?
FICON is features on top of FCS (fiber channel standard). FCS started in the late 80s at LLNL ... it had non-blocking switch with serial copper interface. and LLNL effort to standardize non-blocking switch with gbit serial fiber optic (concurrent gbit transfers in both direction). ESCON had been fiber interface that had been knocking around POK since the 70s. About the time ESCON appeared, one of the RS6000 engineers worked on taking ESCON specs, making it full-duplex (concurrent transfer in both directions), media speed 10% faster than ESCON ... and significantly less expensive (as well as reliable) optical drivers. This was the SLA (serial-link adapter) feature on the RS6000. He then wanted to start work on enhancing SLA (effectively enhanced ESCON) from 220mbits to 800mbits. We had been working with LLNL and convinced the engineer to join the FCS committee rather than doing a proprietary 800mbit SLA (SLA started out being enhanced ESCON). Then in the early 90s, some POK channel engineers started participating in FCS committee meetings ... wanting to layer some unnatural IBM channel features on-top of the base FCS standard (which eventually appears as FICON). There are a lot of FCS mailing list from the period over the conflict layering FICON features on top of FCS. A major part of FCS standard was optimal cost/effective driver speed available at the time ... for commodity priced standard (aka 1gibt/sec, full-duplex, simultaneous transfer in both directions) ... and full-duplex operation used for helping mask end-to-end latency (aka ibm channel protocol operation with half-duplex paradigm was becoming more&more latency limited ... dead-time on the channel waiting for end-to-end turn arorund). Once FCS addressed the end-to-end latency issue ... then changes in media speed was what-ever commodity parts supported at any point in time. In that time-frame, IBM had developed its own serial-copper for disk operation (internal name harrier out of hursley) and announced as 9333. It ran 80mbits/sec ... full-duplex (aka concurrent 80mbit/sec in both direction) using "packetized" SCSI commands ... aka rather than half-duplex SCSI bus signaling ... the SCSI commands were encapsulated in message packets and transmitted asynchronously (using effectively identical SCSI disks ... harrier had significant higher aggregate thruput than equivalent scsi disks in a half-duplex scsi-bus configuration). We tried to get harrier enhanced to interoperate with FCS ... multiple fraction of FCS media ... still using serial copper ... but running into FCS non-blocking switch and speed-matching handled. Instead, it morphed into "SSA" (running at 160mbits/sec in each direction) ... and non-interoperable with FCS. old post mentioning SSA & FCS http://www.garlic.com/~lynn/95.html#13 also references early Jan1992 meeting in Ellison's conference room doing loosely-coupled cluster scaleup ... with proposal to have 128-way configurations shipping to customers by ye1992. 128-way ye1992 would both support numerical intensive environments ... but also use FCS and non-blocking loosely-coupled access to massive disk farm in large-scale DBMS operation (mainframe DB2 people started whining that if I was allowed to continue, it would be light-years ahead of where they were). old email about cluster scaleup ... including several references to LLNL http://www.garlic.com/~lynn/lhwemail.html#medusa -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
