Technical summary - Emulation of hardware platforms
The following technical summary is intended to help you understand some of the key aspects of systems running on emulated hardware rather than physical hardware.
This information is intended to help you understand the emulation process itself and so be able to make a better informed decision about how applicable an emulator might be to your specific situation. It is not trying to present emulators as either a good thing or as a bad thing - they can be either depending upon your specific circumstances, workloads and availability requirements.
There can be issues with availability as your application is now completely dependent on the underlying operating system and the physical hardware platform. There can be issues with the response time aspects of performance, especially in real-time control system environments. There can be issues with hardware support for I/O devices. An emulator will generally have worse latency behaviour than the original hardware, simply because of all the abstraction layers that you have to go through in order to reach the physical hardware.
In mission-critical environments the issues of certification and testing becomes very important. You cannot just move to an emulated machine without thorough validation and testing of the entire underlying platform. Do not underestimate the time, effort and cost involved in that process. In many cases you’re better off sticking with the hardware you know and trust, then building a modern replacement system to smoothly take over from it when you have an opportunity to make controlled changes.
Creating a software emulation of a complex system like a VAX or Alpha is a considerable technical achievement. Software emulation requires a software representation of the instruction set, plus a software representation of the system infrastructure, such as memory and the I/O devices. That software representation then runs on top of a different operating system and a different physical hardware platform. In some cases people choose to run the host operating system as a virtual machine under a hypervisor such as VMware, which can add serious amounts of latency. The success of the emulated system is dependent on behavioural characteristics of the entire underlying platform.
Emulators mimic the original hardware architecture and process the instructions and data of the original software as though they were the real thing. It’s a much slower process in that a lot more machine instructions get executed, but because of the much greater clock speeds of modern machines and techniques such as binary translation and just-in-time translation, they can actually deliver better throughput that the original hardware, although the latency is likely to be worse. The trick to making an emulator work well is configuring it to look like the original system, including all the I/O devices. The aim is that the original operating system and application software, plus your data, remain unchanged.
Remember that the system management requirements for OpenVMS will not go away. If anything you need to have a better understanding of the overall system and the underlying platform in order to make it perform well and to be able to diagnose problems.
If you need help then please ask us. We'll do our best to help you.