A new cluster member
Earlier, I downloaded Personal Alpha – not the full freeware version yet, but a two-month trial one – and installed it on Demeter, the company laptop. Of course, VMS was installed on the disk container, and all that I need to do some investigation.
It works fine – as was to be expected. Not very fast, indeed, but well workable.
As it runs on Demeter, the instance is named “Persephone” – in Greek mythology Demeter’s daughter.
Of course, it would be nice to have it connected to Diana – the main VMS machine – as a cluster member. It works fine over the wired network, though the NIC is not usable for Windows anymore and connecting a Windows process (like terminal emulator or FTP program) is not possible. But it works.
Since Personal Alpha will use the same network connections as Windows, I tried to boot it into the cluster via wireless.
Does that work?
Yeah, why not: VMS = VMS and what’s it running on doesn’t really matter! That’s why WAX, Alpha and Itanium work in one cluster. Though not
- officially
supported (meaning it hasn’t passed rigorous testing) but since clustering is as the bare bones of VMS, it is not a true suprise. The actual product (Virtual Alpha) has no problem with clustering either, nor has Charon-VAX; fopr the very same reason: VMS (VAX) = VMS (AXP) = VMS (IA64) = VMS (CharonVAX) = VMS (VirtualAXP) …. (When will this be extended to IA32???).
The size of operator log incresed – but that was to be expected, (re)booting the second machine several times – and complete, including TCPIP processes. That is is over 4 times in size than normal, has another cause, discussed elsewhere.
However, there is a problem in accessing the MSCP-serverd disks. They can be seen, but cannot be accessed, or mounted. But that happened to Dido as well (except for the shared SCSI disks) so that is a more generic issue.