TCPIP and connecting z to alternate platforms
huge amount of OS-360 TESTRAN was outputing all the (12-2-9) "SYM" cards as part of buttemble-compile ... so that you effectively could support symbolic debugging. I don't know anybody...
Roy Hewitt
Dave Jones well here is a recent posts about some early security issues: As Bad As All That and one of the references from the above: another...
escon technology had been laying around pok since the 70s ... but never actually released (for quite some period). one of the austin engineers took the spec, increased the bit rate by approx. 10percent, went to significantly cheaper optical drivers (order of magnitude cheaper) and made it actually full-duplex (i.e. 220mbits in both direction). it was released as SLA (serial link adaptor) with initial rs-6000. He then wanted to start on 800mbit (full-duplex) version of SLA.
we had been attending various standards meetings in that period ... HiPPI ... 100mbyte-sec parallel copper being pushed by LANL ... effectively standard version of cray channel; SCI pushed by SLAC ... high-speed full-duplex fiber optic for a number of things ... including memory bus (you saw it show up in the sequent 256 processor machine); and FCS pushed by LLNL ... basically a fiber-optic version of some serial copper stuff they had installed.
We convinced the SLA engineer instead of starting work on 800mbit SLA (as upgrade from his 220mbit full-duplex enhanced escon operation) ... it would be better to devote his effort to FCS standard version ... full-duplex 1gbit fiber. After some discussion, he switched and eventually become the editor for the FCS standards document.
for even more topic drift related to that activity when we were working on cluster scale-up
in conjunction with ha-cmp
i.e. in the half-duplex escon 200mbit-sec time-frame there were early installations of full duplex 1gbit fcs (i.e. 2gbit-sec aggregate ... targeted use both processor-to-device and processor-to-processor including tcp-ip)
Later some POK channel engineers started participating ... and I have a huge pile of archived FCS mailing list discussions where the mainframe channel engineers were attempting to layer the half-duplex copper channel paradigm on top of FCS full duplex operation (similar to what had been done for escon) .... cutting aggregate thruput as well as compromising a lot of the latency compensation that comes with full-duplex operation (big issue in various FCS configurations as well as various SCI operations). with enuf latency in half-duplex operation, the latency can start to dominate over raw bit transfer (starting to minimize the thruput difference between 200mbit-sec and 1gbit-sec).
with respect to enet ... machine i bought last year for home use came standard with 10mb-100mb-1gbit enet ... and the next machine looks like it will likely have 10gbit enet.