Over the past half-century, one of the largest trends in the computer industry has been the replacement of mainframes by microcomputers. Not total by any means – there are still many mainframes in operation – but their heyday is long past. The same is true of COBOL, which still in some capacity or other handles a fair chunk of world GDP, but certainly the percentage of commercial code written in COBOL versus other languages like Java, has declined substantially from its peak.
It's interesting to note what has not happened. By and large, COBOL code has not been ported from mainframes. Where it is still running, it is in most cases still running on mainframes. Where they have been replaced by microcomputers, the microcomputers are by and large running code in other languages. This is somewhat counterintuitive. In principle, software doesn't care what hardware it's running on – okay, some software does, if it's written in assembly, or otherwise does low-level things with the hardware, but this would not seem to describe business applications in COBOL. Intuitively it seems reasonable that all that code would start being ported to microcomputers once microcomputers cost less for a given capacity. But that's not what happened, and I'm curious about why not.
One consideration is that the hardware capacity was not there in all cases. Even when microcomputers started challenging mainframes for MIPS and megaflops, they could not match a high-end mainframe on other metrics like storage capacity in the hard disk array, or number of terminals that could be served simultaneously. Still, there was overlap. Consider the IBM 9370: a 370-architecture minicomputer introduced in 1986; it was available with 4-16 MB RAM, 64-384 terminal capacity; that overlaps with the capabilities of contemporary 386 servers; there would be cases where the mainframe was running several applications, at least some of which would use only a small part of its capacity; and of course there would be cases where there was a desire to port code from older mainframes, so the comparison could be with a much later generation of microcomputers. So in some cases, the hardware capacity would be there.
What other requirements? Clearly, a COBOL compiler on the target platform. It is certainly the case that such was available on microcomputer operating systems like CP/M, MS-DOS, OS/2 and Windows, e.g. CIS COBOL and Micro Focus COBOL. Of course, the compiler would need to be sufficiently feature-complete and of adequate quality. This might not have been a trivial requirement, e.g. the former link says:
In the late seventies, the company Micro Focus created Compact Interactive Standard COBOL (CIS COBOL) for 8-bit microcomputers. CIS COBOL is based on the ANSI COBOL standard X3.23 (1974). Due to the memory constraints of 64 kilobyte RAM only Level 1 and a few features from Level 2 are implemented.
Okay, it's understandable that features were limited on 64K machines, but one would expect that restriction to be lifted in a few years. However, http://www.edm2.com/index.php/Microsoft_COBOL says
It should be noted that neither the Microsoft 1.x and 2.x compilers nor the later Micro Focus sourced compilers were in general considered very good even in their day and library support and code quality was considered below par. The Microsoft 1.x/2.x series also had a number of peculiarities that meant that considerable time was needed to port COBOL code to and from the system. The systems were mostly bought by people that needed to do mixed language programming but even in version 1 the support for that was already better than most of their competitors in the DOS world. With release 3 and the inclusion of the "Professional series" tools the support was excellent and the tool would also integrate fully with other Microsoft "Pro series" tools.
And apparently Microsoft and IBM both dropped their independent PC COBOL compilers in favor of licensing the Micro Focus one, despite the above problems. So, not trivial at all.
Still, supposing the target COBOL compiler were adequate, what else would be needed? It is common for software to need more than the language per se. If you have a website written in Ruby, it's likely to also depends on Rails. If you have machine learning code written in Python, it's highly likely it also depends on PyTorch or Tensorflow. If you have business software written in COBOL, what is it likely to depend on? I don't know much about IBM mainframes, but I gather they had:
- JCL, the job control language. Roughly equivalent to bash? Some Linux software has quite a bit of code in bash scripts, that would create nontrivial effort to port to a platform with a different shell. Is the same true regarding JCL?
- RPG, the report generation language, going all the way back to 1959. Roughly equivalent to something like Crystal Reports, albeit without the GUI? Probably substantial chunks of a typical business application could be written in this?
- DB2, a relational database. This actually seems less likely to be a problem, partly because it was first released only in 1983, and partly because there are other relational databases, and the effort of porting between them, while nontrivial, would be less than if you had to port to a different kind of database.
- IMS, a pre-relational database. This seems much more likely to be a problem, partly because it goes back to 1966 and partly because the effort of porting from it to a relational database would be correspondingly greater.
- Other major software components that I'm not aware of?
Which components or facilities were the biggest obstacle to porting typical COBOL applications?
