PLEX86  x86- Virtual Machine (VM) Program
 Plex86  |  CVS  |  Mailing List  |  Download  |  Computer Folklore

Was FORTRAN buggy 4322

Was FORTRAN buggy 4329
On Sun, 24 Sep 2006 11:19:25 -0700 in alt.folklore.computers, John Barry Boehm, et al. Software cost estimation...

part of the issue was that the official-strategic communication product was SNA ... which had effectively large master-slave paradigm in support of mainframe controlling tens of thousands of (dumb) terminals (there were jokes about sna not being a system, not being a network, and not being an architecture).

the internal network was not SNA ...

Was FORTRAN buggy 4325
But there are now. Why should we not use them because they weren't handy when you were working on TOPS-10? I'm not saying that test-driven development made sense THEN. But...

misc. recent threads discussing the announcement of the 1000th node on the internal network

and reference to the approx size of the internet-arpanet in the same timefame (possibly as low as 100 to possibly a high of 250)

in the very early sna days, my wife had co-authored a (compebreastive) peer-to-peer architecture (AWP39). she then went on to do a stint in POK responsible for loosely-coupled architecture (aka mainframe cluster) where she created peer-couple shared data architecture ... except for IMS hot-standby, didn't see a lot of uptake until parallel sysplex

Was FORTRAN buggy 4323
re: oh and some of the dumb terminals weren't necessarily so dumb ... there were also things like huge numbers of ATM (automatic teller...

there were some number of battles between the communication group attempting to enforce the "stratigic" communication solution for all environments (even as things started to move away from the traditional tens of thousands of dumb terminals controlled by a single mainframe). san jose research had a eight-way 4341 cluster project using trotter-3088 (effectively eight channel processor-to-processor switch) that they wanted to release. in the research version using non-sna protocol ... to do a full cluster syncronization function took something under a second elapsed time. they were forced to migrate to sna (vtam) based implementation which inflated the elapsed time to over half a minute. recent reference to early days of the project

another situation was that terminal emulation contributed to early heavy uptake of PCs in the business environment. you could get a PC with dumb terminal emulation AND some local computing capability in a single desktop footprint and for about the same price as a 327x terminal that it would replace. later as PC programming became more sophisticated, there were numerous efforts to significantly improve the protocol paradigm between the desktop and the glbutthouse. however, all of these bypbutted the installed communication sna infrastructure and installed terminal controller product base.

the limitations of terminal emulation later contributed heavily to data from the glbutthouse being copied out to local harddisks (either on local servers or on the desktop itself). this continued leakage was the basis of some significant infighting between the disk product group and the communication product group. the disk product group had come up with a number of products that went a long way to correcting the terminal emulation limitations ... but the communicaton product group continually blocked their introduction (claiming that they had strategic product responsibility for anything that crossed the boundary between the glbutthouse and the external world).

at one point (in the late 80s) a senior person from the disk product group got a talk accepted at the communication product group's worldwide, annual internal conference. his opening deviated from what was listed for the talk by started out stating that the head of the communication product group was going to be responsible for the dissolution of the (mainframe) disk product group. somewhat unrelated topic drift, misc. collected posts mentioning work with blg14 (disk engineering) and blg15 (disk product test)

we were also doing high-speed data transport project (starting in the early 80s)

a recent posting somewhat contrasting hsdt and sna

the late 80s was also in the period were we had started pitching 3-tier to customer executives.

we had sort of melded work that had been going on for 2-tier mainframe-PC and for 2-tier glbutthouse-departmental computing (4341). a few recent postings

Was FORTRAN buggy 4326
I don't believe that there are good emulators. Sure, they're better than before. But they are not good...

however, this was also during the period that the communication product group was attempting to stem the tide away from terminal emulation with SAA (and we would take some amount of heat from the SAA forces).

part of our 3-tier effort we then forked off into ha-cmp

and oft repeated specific posting

for other drift ... a side effort for hsdt in the mid-80s ... was attempting to take some technology that had originally been developed at one of the baby bells and ship it as an official product. this had a lot of SNA emulation stuff at boundaries talking to mainframes. SNA had evolved something called cross-domain ... where a mainframe that didn't directly control a specific terminal ... still could interact with a terminal ("owned" by some other mainframe). the technology would tell all the boundary mainframes that (all) the terminals were owned some other mainframe. In actuallity, the internal infrastructure implemented a highly redundant peer-to-peer infrastructure ... and then just regressed to SNA emulation talking to boundary mainframes.

List | Previous | Next

Was FORTRAN buggy 4323

Alt Folklore Computers Newsgroups

Was FORTRAN buggy 4321