Why? I've been into x86 databases since the Windows NT days and 5000 doesn't seem an impressive number to me.
Windows, let alone Quickbooks is not going to run very well on a machine with just 512MB of RAM.
Also, I can imagine using an Excel spreadsheet with some sheets, thousands of records on each one (Excel 97 max rows was 65536) + formulae and macros even 20 years ago so, again, 5000 doesn't seem an impressive.
I can't remember how much would SQLServer with a database take those days though so perhaps a 4GB HDD might indeed be insufficient.
Doesn't macro32 on alpha or itanium run old VAX binaries transparently? Why keep the antiques? Even SimH seems a better option (assuming the licenses work).
Since I've got actual Vaxen it doesn't help.
Where you have the source, you can build a native binary. Where you lack it, perhaps the emulation is sufficiently robust.
I have keys for the VAX assembler (and Fortran, BASIC, and Ada) so running source, and building applications that DECUS distributed back in the day, isn't a problem for me.
What annoyed me was that VMS/VAX support was discontinued by the hobbyiest program. When it was announced and I asked for details they suggested I contact licensing. Which I did and suggested I could buy new licenses for VAX machines for $5,000 good for up to 25 users. For a machine that was headed for the skip. So someone, somewhere, and I'm thinking US GOV here, "can't" upgrade their VAX hardware and HP has them over a barrel so they continue to hold those licenses as saleable products. But that is purely speculation on my part.
[1] In fact, for the earlier models (anything before the VAX 4000 series), they run faster on a modern PC under simh than they do on the original hardware.
MACRO32 is a VAX assembly compiler - given a VAX assembly source listing, it can turn it into object code for Alpha, IA64 or x86. In some cases, the code will need special annotations.
There's also VEST on Alpha which does translation of user-mode VAX binaries into Alpha binaries. I think that was an optional product. Many products (including things unrelated to the operating system) don't fall into the user-mode category due to the use of the "Privileged Image" mechanism of VMS.
Nitpick: Neither are emulators in the strictest sense of the term.
Which is what I or anybody else who wants to have now anyways. I do not recall my applications "loading their key parts" from various places. Everything is local and native yet connected when needed.
This machine, processed the payroll for a bit over 5,000 employees on a "clustered" machine that had a combined total of 512MB of RAM and 4GB of disk. I can assure you that "Quickbook Payroll" would not be able to handle this on a similarly resourced x86 machine. Not even close.
Unicode support is nice, and the fact that once you've compiled your application to binary it doesn't have to go over the Internet to load key parts is super nice.
And yes, there are people that still use COBOL, still think it is the best choice for the task that it is doing, and keep it going with a modest amount of maintenance.