> At some point, I brought a MicroVAX with me to a vintage computer convention, and a friend had his MacIvory Symbolics Lisp Machine on display. As the two systems were from the same era, we thought that we should try to bring up some network between them. My VAX ran a fairly recent version of VMS, though, and when we tried to establish a DECNET connection, the Lisp machine would signal an error and put us into a debugger. What got me hooked on Lisp was that my friend could display the source code of the failing DECNET device driver, figure out that the problem was the too-new DECNET version number that the VAX had reported in the connection setup packet, fix the Lisp code in the DECNET driver of the Lisp Machine and then continue the file transfer operation that had signaled the problem. I certainly understood that this would theoretically be possible back then, but I had never seen a system that would have that level of integration of operating system and programming language. I was intrigued.
Makes one wonder if an OS should be built using LISP these days to make available that kind of hackability. Or port Genera OS [1] to x86 or arm. The languages used by the VPRI project were bootstrapped on lisp if I recall correctly [2]. It would be great if that projects code was released as open source too.
There is Mezzano[0], but I am not sure if it has a similar kind of hackability. I believe environments like that are pretty amazing. It is something that is not unique to just lisps either, you see similar features in Smalltalk environments like Pharo[1].
The Lisp machine emulator for x86-64 that runs Genera is easy to setup if you care to google around. The current owner of Symbolics displayed interest in open-sourcing Genera a few years ago but nothing happened since then.
Movitz[0] is a Lisp-based environment for x86 hardware. I have only cursory knowledge of Common Lisp and x86 assembly but found the code quite easy to follow. It isn’t under active development but there is nothing stopping you from dusting it off.
The language survey class I took as part of my CSci degree, had us use Lisp on a MicroVAX. The resources that Lisp required versus the machine we were running it on made it very much like programing a batch system. The terminals were slow when Lisp was running. It was so bad we typed our programs out on a PC and ftp'd it up to the VAX and then loaded it, check if we got the syntax right, run it, and repeat. The whole interactive lesson was lost on us since it would take forever to do anything. The only good that came out of it was winning enough money at poker played in the lab to pay for pizza that weekend.
The VAX was really a beautiful architecture and a good fit for systems that ran lots of small processes subsequently. However, it was also notoriously bad at running LISP because of its huge page table overhead. A page was 512 bytes in size, giving an address space of 2^23 pages. So when a process grew larger, the machine started to swap out parts of the page table and everything went down to a crawl. This is probably what you observed.
512-byte pages worked fine on a 18-bit or 22-bit architectures, like the various models of the PDP-10 and the PDP-11, but were simply too small for the VAX. So the VAX did solve the memory shortage of its predecessors, but in the case of LISP at the price of abysmal performance when running memory-intensive applications, which many LISP programs unfortunately were.
This is slightly tangential, but it details my first real professional screw-up on a VMS system.
My first serious job was working as a Junior Sysadmin on a large VAXCluster. I literally had NO idea what I was doing. On my first day my boss said to me, "Here's your account details, it's got the same rights as SYSTEM, if you screw up, we'll fire you. Good Luck.". The senior admin showed me the ropes, and especially the HELP command, and basically spent the next week typing HELP followed by every command I encountered.
Fast forward three months, and I'm fairly comfortable with VMS, writing scripts and improving some of the daily housekeeping tasks to make them faster and more efficient. I'm working on the startup script that boots the cluster, stepping through the existing one to understand what it does and I encounter a command I've never seen before, so I duly flip terminal screens (VT420 dumb terminal with dual inputs), and type HELP followed by the command.
Except I didn't actually type HELP. I just typed the command.
As I watched the terminal fill up with output, I realised what it did. Basically it flushed all core processes out of memory. Including the one that allowed people to logon.
Normally this would be a fairly embarrassing screw up requiring a simple reboot, except that this VAXCluster belonged to the MoD, and it was running military combat scenarios (wargames), and had been running a large war scenario for several weeks, non-stop. Somewhere on the site where I was working, there were two large rooms each filled with soldiers and each day they'd been planning out their campaign tactics against each other and these decisions were being plumbed into the running scenario in real time by an operator.
I'd basically broken everything, and potentially destroyed the whole scenario. The scenario was still running in memory, but no-one could talk to it anymore. Rebooting the cluster was not an option.
Immediately, white faced, I admitted to what I'd done. One of the 'real' VMS coders on my team also went ashen. After lots of head scratching, he set to work. I don't know in detail what he did, but from what I understood at the time, he effectively manually restarted the 100s of processes that the Cluster needed to operate, as if it was rebooting but without actually flipping the switch.
Several hours later, the Cluster was fixed and running normally. I'd also not been fired.
This event, left me with a massive appreciation of multi-user systems and how one small error can affect 100s of people. A year or so later, I transitioned into PC support, as Desktop PCs were slowly replacing the dumb terminals across the site, and later on I started working for an international bank where again networked PCs were new. I found that having cut my teeth and been burned on a large multi-user system gave me an impact perspective that most people working in the fledgling PC support industry didn't yet have.
Because of this, VAX/VMS systems will always be special to me.
12 comments
[ 5.2 ms ] story [ 44.1 ms ] thread[1] http://wiki.c2.com/?GeneraOs [2] http://www.vpri.org/writings.php
Imagine a fully lisp based OS...hmm.... the things you can do!
Peace
[0]: https://github.com/froggey/Mezzano
[1]: https://pharo.org/
Do you know why that petered out? Is there anything in particular that would reignite that conversation?
[0] https://www.common-lisp.net/project/movitz/
512-byte pages worked fine on a 18-bit or 22-bit architectures, like the various models of the PDP-10 and the PDP-11, but were simply too small for the VAX. So the VAX did solve the memory shortage of its predecessors, but in the case of LISP at the price of abysmal performance when running memory-intensive applications, which many LISP programs unfortunately were.
My first serious job was working as a Junior Sysadmin on a large VAXCluster. I literally had NO idea what I was doing. On my first day my boss said to me, "Here's your account details, it's got the same rights as SYSTEM, if you screw up, we'll fire you. Good Luck.". The senior admin showed me the ropes, and especially the HELP command, and basically spent the next week typing HELP followed by every command I encountered.
Fast forward three months, and I'm fairly comfortable with VMS, writing scripts and improving some of the daily housekeeping tasks to make them faster and more efficient. I'm working on the startup script that boots the cluster, stepping through the existing one to understand what it does and I encounter a command I've never seen before, so I duly flip terminal screens (VT420 dumb terminal with dual inputs), and type HELP followed by the command.
Except I didn't actually type HELP. I just typed the command.
As I watched the terminal fill up with output, I realised what it did. Basically it flushed all core processes out of memory. Including the one that allowed people to logon.
Normally this would be a fairly embarrassing screw up requiring a simple reboot, except that this VAXCluster belonged to the MoD, and it was running military combat scenarios (wargames), and had been running a large war scenario for several weeks, non-stop. Somewhere on the site where I was working, there were two large rooms each filled with soldiers and each day they'd been planning out their campaign tactics against each other and these decisions were being plumbed into the running scenario in real time by an operator.
I'd basically broken everything, and potentially destroyed the whole scenario. The scenario was still running in memory, but no-one could talk to it anymore. Rebooting the cluster was not an option.
Immediately, white faced, I admitted to what I'd done. One of the 'real' VMS coders on my team also went ashen. After lots of head scratching, he set to work. I don't know in detail what he did, but from what I understood at the time, he effectively manually restarted the 100s of processes that the Cluster needed to operate, as if it was rebooting but without actually flipping the switch.
Several hours later, the Cluster was fixed and running normally. I'd also not been fired.
This event, left me with a massive appreciation of multi-user systems and how one small error can affect 100s of people. A year or so later, I transitioned into PC support, as Desktop PCs were slowly replacing the dumb terminals across the site, and later on I started working for an international bank where again networked PCs were new. I found that having cut my teeth and been burned on a large multi-user system gave me an impact perspective that most people working in the fledgling PC support industry didn't yet have.
Because of this, VAX/VMS systems will always be special to me.