"At 50 million bucks, why didn't they emulate the old machinery or port the code to an interpreter running on a modern system?"
The hardware isn't an issue with IBM mainframes, even their newest Z-Series implementations are mostly backwards compatible with the 1960's era System/360. I'm pretty sure the cost of new hardware would have been cheaper than porting their software over to a completely new hardware platform and language.
" But (reluctantly...) in all fairness, getting off the mainframe is very VERY difficult,"
Having worked on well over a dozen projects to do just that, this post is 100% on-point, although my success rate has been much better, on projects that span half-a-decade :-) I'm working on one right now to port a COBOL/IMS system over to .NET and SQL Server that has been in the works for over 2 years.
The hardware platform isn't the biggest hurdle (although expensive, it's bullet-proof reliable). The biggest challenges boil down to three things:
1) Business rules coded in languages long considered obsolete (COBOL, JCL, IMS databases) by people who either retired or died decades ago.
2) Data that has been severely polluted over the years, such has having fax numbers in an address field, lookup codes that have been deleted, (although the data remains in place, causing broken referential integrity), etc etc.
3) Business rules that are done more for tradition. A user may have been instructed to do a process a certain way, but no one is sure what the reasoning is for doing it. It may be a valid reason; but that reason was discovered years ago by someone (either retired or dead), forgotten, and has just been done for traditions sake. In cases like this, it's hard to make a case to carry a process like that over to the new system, but it can't just be ignored either.
I'm simplifying #3, but you'll probably get the idea. I think that these three problems could crop up in ANY software system that has been in use for 40 years, regardless of the hardware platform or the programming language. As much as we try to mitigate planning for the future use a system, very few people in our industry really expect the software we write to be in use 40+ years from now. I think Y2K is a pretty good example of that too :-)