I worked on Alpha Micros for several years. They were one of the many proprietary multi-user mini computers of the age that were the go to solutions for small office and departmental applications.
While the AM-1000 was a pretty simple machine (who’s primary novelty was using a VCR as a backup device), the larger machines were more sophisticated. Better processors, auxiliary I/O cards to off load processing, etc.
The OS was not spectacularly sophisticated. Applications had reserved blocks of memory, no real process protection. I won’t say that the machines were unreliable, but they did crash hard, and often enough that we just dealt with it. For our work, we honestly did not interact with the OS is any real detail (beyond editing files, copying files, etc.). I remember talking with a vendor once, asking why the system did not time stamp its files. And he basically said, “And, what, waste a disk write?” Since, yea, it would be an extra disk write to update a timestamp, and, yea, disk write were Expensive.
In our case, we used applications on top of a database development system known as AlphaBASE/Metropolis. This system had several hooks in to the OS, and was, honestly, quite sophisticated for its time. For example, I don’t recall the details, but a AlphaBASE system would restart fast than a stock AMOS system. As one of the salesmen noted at a convention when the box crashed “But look how fast it boots!”.
All of our code was in BASIC. I don’t think it was the stock AMOS BASIC, as it had special features that the stock one did not.
Metropolis had built in support for ISAM files, which were our bread and butter. In this case, as the developer, we were responsible for updating not just the records, but all of the keys as well. If a table had four keys associated with it, we’d have to insert a row in to the table, and then insert the four keys as well. The bright side is that you could have conditional keys (just don’t update them). But the dark side is that non of this was transactional. It was routine maintenance when something went amiss to have to rebuild all of the keys in the system. If the system crashed mid update, it was very easy for the records and the keys to not be in sync.
As I said, the machines were not unreliable, but computers and computer, software is software, and crashes happened. Today, with modern SQL databases and transactions and such, we rarely worry about a hard crash corrupting your DB. Back then, it was a routine concern.
At the same time, however, Metropolis offered a feature that was novel at the time. The BASIC supported this concept call “GENCODE”. GENCODE did exactly that – they generated code at compile time. Earlier, I said we’d have to update all four indexes when updating a row. In practice, we didn’t. We would use a GENCODE command that would generate the proper calls for us. This way, when we added an index to a table, we just had to rebuild the software, rather than recode and update it.
Today, you might consider a GENCODE as a macro. GENCODEs were used throughout the system and gave us sophisticated record management and screen control for our screen forms.
For such a crude box, Metropolis was a pretty neat system. Beyond the development environment, it also offered us things like multi-session terminal management and instant messaging. It utilized the color terminals we had to hilt, providing really attractive screens.
We made some pretty nice systems on top of the AM, supporting 100’s of on line users. We had one system with two machines networked together (TCP? What’s TCP? No, this was some serial thing they had.). We definitely made that machine dance.
Solved some really interesting problems.
We eventually moved on to UNIX and other DB systems.