How was it possible to run IBM mainframe software in emulation on HP?

Question

... 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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.