Poring or rewriting Tru64 software

Sometimes it happens that an organization is stuck with old software running on the Tru64 operating system on Alpha hardware. Usually such an organization suffers from some of the following problems.

  • The hardware is old, the ownership costs and failure risks are high.
  • The old software cannot easily be modified and extended
  • The programmers with the skills in Tru64 and the programming language are hard to find
  • The software cannot easily be integrated into the modern settings or cannot interchange data with modern software peers.
  • The software performance cannot be increased, because it is running on slow old hardware.
(more…)

Porting or rewriting OpenVMS software.

Sometimes it happens that an organization is stuck with old software running on the OpenVMS operating system on VAX, Alpha or Integrity hardware. Usually such an organization suffers from some of the following problems.

  • The hardware is old, the ownership costs and failure risks are high.
  • The old software cannot easily be modified and extended
  • The programmers with the skills in OpenVMS and the programming language are hard to find
  • The software cannot easily be integrated into the modern settings or cannot interchange data with modern software peers.
  • The software performance cannot be increased, because it is running on slow old hardware.
(more…)

Tru64 emulator

AlphaVM does not actually emulate Tru64 (aka Digital UNIX, DEC Unix, OSF/1). AlphaVM emulates the DEC Alpha system hardware. As the result Tru64 runs on the virtual hardware unmodified.

In fact, for the user it may look like Tru64 runs on the Intel x86-64 based hardware. AlphaVM is a software layer that makes it possible.

(more…)

OpenVMS emulator

AlphaVM does not actually emulate OpenVMS. AlphaVM emulates the DEC Alpha system hardware. As the result OpenVMS runs on the virtual hardware unmodified. Since the emulated hardware is Alpha, it is OpenVMS/AXP that runs on AlphaVM.

In fact, for the user it may look like OpenVMS runs on the Intel x86-64 based hardware. AlphaVM is a software layer that makes it possible.

(more…)

AlphaVM is an Alpha emulator

AlphaVM is software that emulates an DEC/Compaq/HP Alpha system. In other words, AlphaVM is software that creates a virtual Alpha system. AlphaVM is a whole system emulator: it emulates the whole hardware system including the CPU, the core logic chipset, the storage and network controllers, the disks, the tapes, etc. AlphaVM run on Intel Xoen based hardware. Thus, the emulated CPU architecture is different from the host CPU architecture. It makes this product makes it different from virtualization solutions like VMware or Hyper-V, that virtualize systems with the same guest and host architectures.

(more…)

Virtual Alpha system performance

There are many aspects in a computer system, whose performance can be important. For instance, we can talk about the CPU performance, the disks read or write speed, the network throughput, etc. A virtual Alpha system in the same way has the same performance parameters. However, these parameters are usually not proportionally slower or faster on the virtual system with respect to the real system. For instance, the CPU of the virtual system can be faster than of the real one, while the network speed is slower.

Therefore, when reasoning about the performance of some application, it must be specified, which performance aspects are important for this applications. For this reason some applications are called CPU bound, some IO (disk or network) bound.

In many cases the performance is not really important at all. If the application is usually idle and sometimes does short computations and data transfers, the performance will hardly be an issue.

Please check the benchmark page for the comparison of various aspects of AlphaVM and real Alpha performance.

(more…)

Virtualization vs refurbished Alpha systems

Alpha systems that run in the factories and offices are old now. Many of them are used for critical tasks. The risk of failure increases with the flow of time. The support and maintenance are expensive. There are the following main ways to solve the problem:

  • Migrate to a virtual Alpha system using virtualization software like AlphaVM
  • Purchase a refurbished Alpha system to replace the existing Alpha system.
  • Port the applications software to run on modern hardware and supported operating system (Windows, Linux).
  • Write the software for modern hardware and OS from scratch.
(more…)

AlphaVM is a virtual Alpha

Our product AlphaVM can be used to create a virtual Alpha system(s) running on your Intel Xeon based host system. It allows to get rid of aging Alpha AXP based hardware. AlphaVM is a virtualization solution for DEC/Compaq/HP Alpha AXP systems. The AlphaVM solution is based on an Alpha system emulator. AlphaVM emulates a whole Alpha system. It emulates the CPU, the motherboard core logic chipset, the SCSI controllers, the disks, the tapes, the Ethernet controllers.

(more…)

Using COM3 and COM4 in Tru64

Usually an Alpha system has one or two serial ports. The first port is often used as a serial console. AlphaVM currently supports only serial console. Thus, there is only one serial port left for other purposes. Often it is desired to have more serial lines. Therefore, since the 1.6 release our implementation supports additional COM3 and COM4. The guest OS (OpenVMS or Tru64) has to be configured to use these additional ports. The serial drivers have to be loaded.

The additional serial lines are serial ISA devices, the same as COM1 and COM2. Our implementation registers the devices in the ISA configuration table. When a serial driver is loaded, it uses the information from the ISA configuration table.

Below are the instructions.

  • Edit the kernel configuration /sys/conf/EMU. Add the new serial lines after ace0 and ace1.
controller ace2 at isa0 slot 2 vector aceintr
controller ace3 at isa0 slot 3 vector aceintr

  • Rebuild and copy the kernel.
# doconfig -c EMU
# cp /vmunix /vmunix.saved
# cp /sys/EMU/vmunix /vmunix
  • Create the device nodes.
# cd /dev
# ./MAKEDEV ace2 ace3
MAKEDEV: special file(s) for ace2:
tty02
MAKEDEV: special file(s) for ace3:
tty03
  • Optionally, enable the tty02 and tty03 for logging in. Add the following lines to /etc/inittab
tty02:23:respawn:/usr/sbin/getty /dev/tty02 9600 vt100
tty03:23:respawn:/usr/sbin/getty /dev/tty03 9600 vt100
  • Optionally, enable root login. Add /dev/tty02 and /dev/tty03 to /etc/securettys.
  • You may also need to edit /etc/remote. For instance, add
line2:dv=/dev/tty02:br#38400:pa=none