This morning I wallowed in introspection, esp. about where we are with the Internet. My computer communications experience goes back over 30 years now, to a time when 110 baud was the standard for communications. Indeed, it was just about 30 years ago that I moved to D.C. to take a job as a programmer at the Census Bureau preparing for the 1980 Decennial Census. And to my delight, the agency was moving just then from 110 to 300 baud. And, instead of decks of punch cards, we could actually key in our programs. We had a terminal room that would support about half of us at any one time, and we would fight over the Omeron terminals, because they were superior to the older Hazeltine ones.
Twenty-five years ago, I was starting to work in data communications. My initial project was to get the Sperry (now Unisys) DCP front end processors to communicate well over async connections to dump terminals like the Omerons and Hazeltines above. By then, we had mostly moved to 1200 and 2400 baud. Shortly thereafter, after fixing the DCP problems, I moved to remote batch or remote job entry. This was primarily a question of remote printers to print out the results of what the programmers did on their dump terminals.
By twenty years ago, I was firmly ensconced in the data communications world. By then, I was at the USDA site in Fort Collins, supporting the largest remote batch configuration in the world - we supported some 3,000 remote printers/card readers - though many of them were really mini-computers by then, and this was an early mechanism for computer-computer communications.
Because of the logicistal nightmare of supporting over 3,000 remote sites over primarily dial-up lines in this manner, we developed at that time a remote batch protocol that ran over X.25. Our management divided us into two teams, the alligator fighters and the swamp drainers. I was happily a swamp drainers. And, indeed, after a year and a half of development, the project was rolled out to the Forest Service, and it was an immediate success with them, and with us. Within a couple of months, the entire team of almost a dozen alligator fighters could be reassigned, as trouble calls dropped 95+%.
The problem was that this project was so successful, that the Dept. of Agriculture wanted us to implement something like it across their other 5,000 or so remote sites. Unfortunately, this meant dealing with a lot of other vendor equipment, notably IBM, its mainframes, and some of the most atrocious minicomputers ever built. It was a System 36 or 38 or something like that, and it didn't have an async interface, which made communicating with Telenet/Sprint over X.25 problematic. IBM of course assummed that no one would want to communicate between their minicomputers and anything except their own mainframes over a channel connection. This sort of thinking didn't work well with the DoA, with its 5,000+ offices, with at least one office in each county of the country, esp. since the remote ones were by sattelite. Oh, and the X.25 provided the agency (on an agency wide contract) provided for async/TTY access.
Indeed, one of the breakthroughs for reliability in our remote batch project above was when we, as a central site, got direct X.25 connections to the Telenet network. Interestingly, we had a T-1 into the building, multiplexing up to 24 56kb channels. We never used more than a half a dozen of them. The channels were syncronous, so were capable of two or more times the speed that those same lines would have been capable of if running async (and now, we are nearing 56kb on those very same channels).
So, we started a development project for the next generation of remote batch to handle all of the departments computers, minicomputers, and, now, amazingly enough, personal computers.
The first step was to immerse ourselves in the OSI model. The government (Sperry's biggest customer by far) had mandated that all of its future procurements would be OSI compliant, and so all the computer companies were madly trying to implement it. On the other hand, our chief architect / consultant had worked on the original Arpanet program designing TCP/IP. We spent about a year evaluating TCP/IP and trying to bring up a pilot project. But that had a lot of problems:
- TCP/IP was not OSI compliant, or even close. Instead of a seven layer protocol, it was really only about 4 layers. As noted, the U.S. government had mandated OSI compliance.
- At the time, TCP/IP was running through IMPs. These were dedicated processors that communicated among themselves using their own protocol. We were still a couple of years away from it being implemented over Ethernet, etc. Indeed, Ethernet was brand new, and competing with other technologies such as token ring for acceptance. The betting was on the later, since it was being pushed by IBM.
- The Sperry (soon to be Unisys) solution ran through DCP front end processors and worked well with IMPs. But the DoA needed it to run over X.25 (from Telenet/Sprint). The Sperry implementation was highly layered and structured, in keeping with the, then current, drive towards OSI. And we were having a horrendous time translating between IP addresses at the top level and X.25 addresses at the bottom. All of the data structures were just too short to accomodate those long X.25 addresses (remember, IP addresses are really only 32 bits long).
Today, I could probably implement a solution to that problem in a day or two, but we now have huge disk drives and a lot of other capabilities. Indeed, one very quick and dirty solution would be to use DNS forward and reverse lookups. Indeed, after working with the Win 2003 DNS server software last night, I think I could get it to work there fairly easily. But that wasn't an option back then. DNS is robust now because it has to support millions of computers around the world. Back then, Arpanet only needed to support a couple dozen hosts around the country.
In the end, we opted for a rewrite of our original remote batch (RB) protocol. I left Sperry right after it merged with Burroughs to form Unisys, and spent the remainder of the decade working as a consultant for the DoA during the day and going to law school at night. One of the reasons that I was hired as a consultant was so that I could implement the RB protocol on IBM mainframes. So, I learned a lot about MVS internals. We had two competing designs: mine, and the one for the Data General machines. In the end, my design was portable enough that we were able to port it to run on the IBM mainframes, PCs, some IBM minis, DEC minis, and even the DG minis. Unfortunately for IBM, my design called for what was essentially an in-memory database, and I implemented this in MVS using their Data In Virtual (DIV) subsystem. Unfortunately for all concerned, this feature, that had been around for awhile, was untested, at least until I got my hands on it (it was a horrible design on IBM's part, since it was built over VSAM - which went into update mode when a file was expanded, locking out all other users, and I was sharing it among several processes).
A little over 15 years ago (1990), I graduated from law school and got laid off my consulting contract, all within two days. My wife at the time (laid off at the same time) went to work as a network administrator, and as a result, suggested that I get involved in some discussion groups to follow the law, esp. as it relates to where I was trying to go, which was into computer law. At that time, the Internet, as it was, was primarily email, news groups, and ftp. It was also mostly dial up, except for some lucky corporate users. I think the modems were mostly about 12k or so at the time, though I do remember them being able to downshift to 2400, and maybe even 300, if necessary (the big reason for this for me was Nistime - to get the time of day from the Bureau of Standards (now NIST)).
One of my only clients that first year was involved in BBSs (Bulletin Board Systems). They were disabled and ran a yearly BBS convention to make a little money. Someone had grabbed their convention away from them, running one at the same time in the same city with a very similar name.
Twelve years ago, I took a job with Motorola Semiconductor sector in Austin. Initially, we had internal email (all Mac based), as well as some external email. It was about this time that Mosaic really got going, and I would use such at home using a dial-up modem. At some point, the company switched from an Apple to a TCP/IP internal network.
About a decade ago, the VP running our office got Web access into his office. He also provided limited access to the dozen+ patent attorneys in the office for officially sanctioned projects. This lasted about six months, at which time, he was overriden by the powers above him, who mandated that we all get access. Of course, there wasn't that much content available back then, but...
Maybe eight years ago, I jumped to Bull Worldwide Information Systems in Phoenix, a manufacturer of legacy mainframe computers. Web access was fairly universal by then at work. At home, I spent a couple of years fighting to get either cable or DSL service. The problem was that I was living in a new subdivision - which had been built just before Cox and Qwest had started putting in broadband support as standard. So, both companies were spending their money upgrading older neighborhoods. It was only when I moved into one such about sxi years ago, that I could finally get broadband (in that case, Cox cable).
One of the highpoints at Bull was being on their Y2K management committee, and was second level support (for legal matters) at the rollover. That meant that I had to be in town, available by phone, but didn't have to be at the command center at the plant. Interestingly, Bull had installed any number of now obsolete computer systems around the world, and many of their former customers were still running such. The biggest worry, from a political point of view (since Bull is French), was the Swedish National (electrical) Grid (SNG), which was I think the only company in the world running one long discontinued system. A big sigh of relief from all when the rollover came through Europe, and Sweden didn't go dark.
As a slightly related and somewhat interesting side note, Bull was by then the owner of the Multics OS. I was involved in finally shutting it down. Multics, of course, was the basis for the design of Unix (though Multics, being mainframe based, had much better security). And a lot of the Unix command language ended up in DOS, as well as being the basis for Linux. The most engineers at Bull were fairly militant on the subject: Multics was a far superior product to GCOS, but it had lost out through Honeywell company politics.
Five years ago, I found myself at a law firm in Salt Lake city, just in time to see the 9/11 coverage on the big screen TV in the conference room there. By then, I was writing a lot of patents on web interfaces, and remember complaining to the firm's PR person about the firm's Web site - on how it would fade in, and then you would have to click to get to the real site. My point was that the target audience for a patent firm is engineers, and engineers are turned off by that sort of inefficiencies.
Of course, looking back at that today, I think that their web site was fairly inocuous, esp. compared to many I see today. It was in SLC that I discovered that I can't work as a patent attorney withoug good Internet access. Everything is so much more quickly available on the Web than it used to be. I no longer buy most of the books that I needed when I entered patent law 15+ years ago. Rather, it is at my finger tips (or, more accurately in many cases, only a mouse click away).
Indeed, the Internet and the Web have become so ubquitous that there are many businesses in which a web presence is required. Back when I was entering patent law, having email did that. Not any more. I know two artists who now have web sites for just this reason. Not techie attorneys like me trying to practice computer and cyber law, but artists.
Labels: Computers
