We knew from the beginning this was going to be a challenge. There were many big payers with large teams. We had a small team. Our advantage was agility and the ability to think outside of the box.
I had been locked out of the computer room in my high school for accessing the school database. It was not hacking. It was open without controls. It was a simple list command and I did not try to hide. It was a lesson on how little even experts knew about the internet and networks.
Our first task was creating a dial up terminal to get into the UUNET network. It was a simple box with a motherboard, hard drive, screen and monitor. A hard drive was a luxury at that time in history.
We were able to find UUCP sites through Usenet newsgroups so we knew this function was online and working. We could access ExecPC BBS through our old dial up BBS Terminal. We had access to the pieces now to build a box to access both at the same time and register users and copy with UUCP and create a Custom Usenet Reader App.
First step was to build a custom OS without template libraries using "C" to create a custom Minix OS for creation of a new network address APPNET.
The architecture of the gateway was to have a repository of apps and data store with global APPNET Account Access & User App profiles. It is fascinating to look back at what we were building.
We had decided on the employment vertical before insurance as our inquiries into insurance had created concern and potential legal action if we listed insurance firms or agents so we left that for the second challenge.
We wanted to build the box so once we had the employment databases working through the gateway we could then simply setup a new Theme User Profile and start on the Insurance Vertical with simple changes to the fields.
We knew this was a new idea and we needed to self finance. In the late 80’s speaking to someone about helping with a project to create a gateway to deliver applications over UUNET for different industry verticals was like speaking a foreign language.
“We built the box in record time for a small team. Less than six months. We found a hard drive upgrade that was compatible after days of working with DIP switches. We setup two 16-Bit 56k modems to sync networks and Users. The solution was part of the Micro Channel technology called “Bus Mastering”. With bus mastering, each card could talk to each other directly.”
We were very fortunate Tanenbaum was changing world of OS and Database architecture including for microkernel based Unix/Linux. The previous was a main frame monolithic version that we neither had the time or resources to customize and build.
We had two very important structural changes that allowed us to develop this new idea. Sockets Tanenbaum was using in his C programming of Minix as well as the foundations for micro channel support (MCA). These were the only reasons a PC based ASP system was possible.
There were many pieces needed to make this work. The only hardware that would work was the IBM PS/2 at the time being sold at a discount even with micro channel bus. The only version at the time that had the micro channel architecture (“MCA”) was the 286 version which we rebuilt into a server box and installed the updated Minix APP OS 1.1.
The IBM PS/2 was our savior. Micro Channel Architecture (“MCA”) versus the simple 16-bit AT ISA bus. It could support multiple modems on the same PC server. The PC/2 with Intel 286 processor with MCA was only released in 1987 and not easy to find or get.
“In 1991 Minux released version 1.5 which included MCA. It should be noted that it was not until 1991 that Minix 1.5 was released by Andy Tanenbaum with micro channel support. We had custom coded a version of the open source Minix 1.1 just to have a working box with micro channel architecture.”
Micro Channel was the solution for APPNET and we could rotate the cards with 12 milliseconds busts. This was long enough to permit the systems to work with the bus and buffer inbound data from over-runnable devices including hard drives.
Next collision arbitration overcome by the engineers at IBM meant we could have multiple bus-master support and improved arbitration to share the system so bus-master-capable devices could talk directly to each other (peer to peer) at speeds faster than the system CPU, without any other system intervention. This was a solution that was easier said then done. We had to first create the protocol for peer to peer versus CPU processes.
We tested the Hayes modems for DSL and Dial-Up. UUNET founded in 1987 was one of the largest Internet service providers and one of the early Tier 1 networks based in Northern Virginia. One of the first commercial Internet service providers being used and adopted through the University networks. We setup UUCP to make this work.
It was not until 1988 that we had a working application service server.
“It was 1988 and we were about to be hit with a shock to the project. We had been able to tap into UUNET using Dial Up, now we needed to pay $1,500 a month for access to the T-1 Network and advertise our UUCP. We had gone from extreme development to get the box working to a disaster. We had to regroup. I had to finish my real estate project to pay for all the bills and refocus on corporate customers.”
We decided to use the Minix file system for the quickest implementation possible. We had MCA working with two modems simulateously. We had the hard drive booting with MCA. We needed to develop the Minux file system for APPNET login and User App logins.
A rudimentary Minix File System was introduced in late 1987. A customized version worked to set up the Minix file system as part of the boot package of disks. Although basic and filenames of 14 characters or less it worked for our purposes. We needed data access for multiple users. We needed APPNET login. We needed User APP sub account logins. It was our own version of a virtual file system for the server so it could act as an intermediary for data and access.
That was when we realized we needed to have scaled systems for User control, for the outsourced BBS as a global repository for all postings. We needed to be the intermediary of disparate systems. We were going to need to provision for scaling of systems. That process came later with the launch of Milinx.
There were many pieces. The OS or Minix, the hardware being IBM PS/2, the file system being Minix, Micro Channel bus-mastering, multiple modems, multiple users, shared data and a central point on the network for all that to happen with arbitration working to avoid crashes.
We had built our own intermediary for data and users. Now the big shock. UUNET formally became a paid T1 service. It was a shock. Now we needed to pay $1,500 a month for access to the UUNET T-1 Network. We had gone through extreme development to get an application server working. We had to regroup. I had to finish my real estate project to pay for all the bills and refocus on corporate customers.