5

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

1
  • 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 '20 at 16:30
11

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.

1
  • 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. – ConcernedOfTunbridgeWells Nov 26 '20 at 0:56
9

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.

4
  • 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 '20 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 '20 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. – Mark Morgan Lloyd Nov 25 '20 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. – another-dave Nov 26 '20 at 1:23
3

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.

2
  • 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 '20 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 '20 at 2:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.