... At least, without getting sued into the ground?

According to one of the answers to What was the most critical supporting software for COBOL on IBM mainframes?

We installed a new HP replacing an IBM system, and part of the installation was a emulator to run IBM code on the HP.

I haven't been able to find any likely reference to that emulator on Google. Closest thing I could find was an emulator called Hercules, which was first released in 1999. However, apparently IBM explicitly refused to license any of its operating systems for running on Hercules. Hobbyists might try it anyway with a pirate copy of an operating system just to play around, figuring probably rightly that IBM won't care, but a business would find it highly inadvisable to go that route.

And indeed, a comment to another answer:

It goes without saying that the mainframe middleware is heavily encumbered and protected by NDAs etc. No matter how supportive IBM might appear to be of cut-down versions of e.g. their MQ products running on unix or Windows, you can bet your life that anybody who tried to emulate every mainframe nuance would find themselves tied up in court for a long time.

That sounds plausible. Yet if IBM would react like that to someone emulating their middleware, surely they would react even more aggressively to emulation of the entire platform?

So what was the emulator on the HP referring to, and how did they get away with it?

  • 3
    The case was about video game emulation specifically, but I'm wondering how the Bleem case (which ruled that emulating the playstation, and by extension other systems, was legal) might play into this.
    – Hearth
    Nov 25, 2020 at 16:30

4 Answers 4


I don't know what environment they installed to run their software on the HP. The vendor did all the work. For all I know it was just raw COBOL with an IBM compatible runtime running on top of HP-UX. The most notable thing was that it require 3270 terminals (mostly unheard of in the Unix world).

Recall a couple of things.

All the IBM machines are, and have been for some time, large virual machine runtimes. Code is not compiled for the underlying hardware, it's compiled to a virtual machine, which is then loaded to work on the actual underlying machine.

While a mainframe is particularly sophisticated, that does not mean that the actual applications are particularly sophisticated. This was a Hotel Management and Reservations System. COBOL is not a particularly good system programming system (if this was even written in COBOL, that's an assumption). It's high level business system designed around screens and reports. You don't need cycle accurate systems to run most COBOL applications. You simply need to be able to support the file system, printer, and screen interfaces. And, perhaps, some JCL glue that may come with the application as wrappers for workflow and such.

So, I doubt they were actually running a "virtual" mainframe, rather I think they had a compatibility layer supported by their development environment that made porting their software straight forward, down to using the 3270 terminals.

Consider the software that we sold and wrote was written to a P-Code, with the runtime ported to a bunch of different systems. As needed, the code could be compiled to binary for specific machines, but, like Java, the P-Code was portable as is as long as the runtime was installed.

In our case the P-Code was adequate for the vast majority of programs, but we suggested compiling the most common, large programs not so much for raw performance, but simply for memory space. Compiled code shared the executable pages across the many users, whereas the P-Code did not and thus had a larger memory footprint when 10 or 20 users are running the same program.

  • 2
    That's the case with the i Series, but not so much for their z series. However, there are third-party tools (e.g. Micro Focus COBOL) that will compile IBM COBOL apps for other architectures. Nov 26, 2020 at 0:56

There were a number of companies offering IBM 'compatible' mainframes - Hitachi, Fujitsu and Amdahl come to mind. IBM got slapped with an anti-trust suit when it tried to limit their operating systems for their machines only. There was also a lot of business in after-market terminals, printers, tape and disk drives etc.

Amdahl was particularly successful in producing faster and cheaper machines than IBM. Thus, running IBM code on other machines was commonplace.

  • 1
    But I think the difference with Amdahl, Fujitsu, and Hitachi, if I’m not mistaken, is that were truly “compatible” with IBM 370 mainframes. They would even run IBM operating systems and were able to use IBM peripheral hardware.
    – mannaggia
    Nov 25, 2020 at 12:53
  • 1
    @mannaggia Well, they were truly "compatibile" until you tried running some real applications and found that they weren't. Gene Amdahl had the advantage of being Chief Architect of the S/360 OS while at IBM. The others didn't have so much undocumented information carried around in their heads.
    – alephzero
    Nov 25, 2020 at 16:42
  • 1
    That is one reason why IBM has a somewhat uncommon definition of "microcode". The public interface to their mainframes is (generally speaking) well-documented, but the microcode that underlies it is considered to be part of the hardware and is protected as such... even if everybody else would call it a run-time library or emulation layer. Nov 25, 2020 at 22:08
  • 2
    @mannaggia - it doesn't seem to me (not a lawyer) any difference whether you implement the S/37O ISA in microcode or in software. In both cases, you have one execution engine programmed to interpret the S/370 ISA.
    – dave
    Nov 26, 2020 at 1:23
  • @MarkMorganLloyd are you sure you aren't getting confused with IBM AS/400 (nowadays rebranded to IBM i)? What you said is basically true for the AS/400, and its System/38 predecessor. But IBM never classified them as "mainframes", rather "midrange". For mainframes proper (360, 370, 390, z), not really – IBM z microcode is secret, but the same is true for Intel x86-64 microcode. Whereas for 38/400, IBM redefined the term "microcode" to include not just CPU microcode, but also the lower levels of the OS Jun 26, 2023 at 3:09

People have written products to enable re-hosting of IBM mainframe applications on to other platforms, especially Unix. Rather than CPU emulation, these generally work by combining a COBOL compiler (often Micro Focus) with a from-scratch emulation of major mainframe APIs (CICS, IMS, VSAM, JCL, JES2/3, etc). The emulation is always incomplete (only a subset of the API calls are implemented), but implementing the most common calls is generally sufficient for many applications to run – and there are often workarounds for what is missing (change the application code to remove the unsupported call, or write a custom implementation of it just for this project.)

Since 3270 is a publicly documented protocol – and is easier to support now everyone uses it over TCP/IP (via TN3270) – many of these products actually still serve up the application over 3270. This can make the migration very seamless for end-users, continuing to use their existing 3270 terminal emulator, with (at worst) just some minor configuration changes required. (However, if we go back to the 1980s/1990s, you could actually buy hardware to connect real physical IBM 3270 terminals to non-IBM hosts, whether directly or over SNA – I believe Tandem in particular supported that, so you could swap your existing IBM mainframe for a Tandem but maintain your investment in 3270 terminals.)

Examples of such products include:

  • Oracle Tuxedo Application Runtimes for CICS/Batch/IMS. This product includes emulation of (subsets of) CICS, IMS, JCL, JES2 and JES3. Also supports integration with The Workstation Group Ltd's uni-SPF emulation of ISPF and uni-REXX emulation of REXX. (IBM mainframe REXX has lots of mainframe-specific features which aren't found in REXX implementations for other platforms). I don't know much about the history of the product, especially any pre-Oracle history (AT&T invented Tuxedo, who sold it to Novell; Novell then sold it on to BEA; then in 2008 Oracle bought BEA; but that's the history of the Tuxedo core, as opposed to this mainframe rehosting add-on.)
  • Eden server by Rosebud Management Systems – emulates a subset of CICS and VSAM on Microsoft Windows. Although that website reports the product is still "Active", I can't find any website for it or the company, suggesting maybe it isn't.
  • Sun Mainframe Batch Manager (MBM) provided an emulation of JCL under Solaris. Similarly, Sun Mainframe Transaction Processing (MTP). According to one article, Sun acquired this product from a company called Critical Path in 2001, and resold it on to Clerity in 2006. According to this, Clerity renamed MBM to UniKix BPE, and then Dell bought Clerity in 2012. It appears Dell more recently sold UniKix on to NTT DATA. UniKix was apparently originally developed by Bull SAS. Sun MTP became UniKix TPE.
  • Micro Focus has a similar product to emulate mainframe software on Windows, Mainframe Express. However, at least at present, they seem to be targeting it more as a local development environment than rehosting.
  • Not mainframe, but should mention California Software Product's BABY/400, which ran IBM RPG code on DOS, Windows, OS/2 and Netware, along with an emulation of a subset of the AS/400 APIs. They also had emulation packages for IBM's earlier S/34 ("BABY/34"), S/36 (BABY/36 and S/38 (BABY/38) midrange systems.

The above list is (I'm certain) incomplete; if you spend some time digging around lookupmainframesoftware.com you'll almost certainly find more. Searching old trade magazines (Computerworld, etc) would also be likely to turn up more examples.

So, no idea what specific product the author of that answer was referring to (and they might no longer remember, or might not have ever known to begin with). However, I think it is highly likely it would have been recompiling the source code to run under one of these "application level" emulation solutions (whichever specific one it was, quite possibly not any of the above-listed), as opposed to trying to run the actual mainframe OS under CPU emulation.


Micro Focus COBOL will emulate at least 20 different COBOL dialects, and can compile and run on various platforms, including HP/UX (at least in older versions). It even has a CICS emulator. It's possible that the vendor was using this tool, or some other mainframe COBOL porting tool to move the application to the HP.

  • 1
    Seems likely to me - the CICS emulator goes a long way to providing the "platform" needed for many legacy apps of this kind.
    – davidbak
    Nov 26, 2020 at 1:45
  • 2
    Plus IIRC the COBOLs used like this supply runtimes that emulate the standard file access modes of IBM Operating Systems - especially for their record-oriented modes (fixed and variable length, with and without indexing) that modern file systems don't natively support.
    – davidbak
    Nov 26, 2020 at 2:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .