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?

  • 6
    Could it be the time it would take to double check all corner cases that all output data really becomes what you expect that get them to refrain to leave a perfectly working system?
    – UncleBod
    Nov 24, 2020 at 5:53
  • 2
    @UncleBod Sure, for some customers, 'safest approach of all, stick with the mainframe' was and is compelling. But then again, there have been many customers for whom 'spend a zillion dollars rewriting it all in Java, with uncertain prospects of success' looked like the least bad option. Surely for at least some of them, recompiling the COBOL on a different platform would have been more appealing had it been an available option.
    – rwallace
    Nov 24, 2020 at 5:56
  • 2
    Mainframes are very very good at what they do. COBOL is very efficient for moving data around and simple calculation which is what many business applications need to do. The only reason that it is even considered moving away from mainframes is because they are expensive. But, so are supertankers. Nov 24, 2020 at 10:39
  • 4
    Add CICS to your list. And don’t forget that although the COBOL language itself is mostly portable, it did have pieces that were closer to the hardware or environment that it ran on, like the ENVIRONMENT division or extensions like COMP formats.
    – mannaggia
    Nov 24, 2020 at 11:22
  • 4
    First, COBOL exists/is available on all of those platforms that you mention, porting the language was never the issue. Mainframe COBOL apps were never ported to these platforms largely because both the mainframe vendors and the insular group of people who developed and supported them didn’t want them to be ported there until long after the available expertise and market leverage had diminished to the point that it was no longer feasibly possible. This was a problem created entirely by industry marketing strategies and personal career goals. Nov 24, 2020 at 17:21

7 Answers 7



Which components or facilities were the biggest obstacle to porting typical COBOL applications?

Simply that there were not many applications that made sense to be ported to (desktop) micros. If at all, downward migration of whole applications was toward /3x systems and ultimately AS/400, which was well supported and rather painless.


While I don't directly see it in this question, there are two common misconceptions when it comes to mainframes and their usage/software:

  • Mainframes are like micros, just older and eating up more space.
  • Mainframes were used much like micros today, just with text based terminals.

No, they are not and they were not.

Mainframe applications are about data processing, not computing. They are not about interactive use (other than data entry, that is). And they are never about private data stacks, but company wide repositories. For 90% of all mainframe software, there is simply no use case on and for a desktop machine.


Which, BTW, is also why that created a bias against the whole idea of micro/desktop computing and, AFAICT, the major issue behind next to no mainframe manufacturers catching the micro computer wave in time, and often butchering the (unixoide) mini business as well. Management simply didn't see why anyone on earth would want to run a logistics consolidation system on a desktop, and couldn't imagine other applications. After all, their secretaries already had nice Selectric typewriters, what more could they want?


Comparing mainframes to micros is like comparing a 40-ton (18-wheeler, road-train, pick whatever is king on your roads) with a family sedan. The sedan is meant to ferry the owner and optionally bring little stuff along, with a focus on getting everywhere, while the lorry is meant to transport with its driver having no intent to get there being rather the operator necessary. It can't get everywhere, but where it gets, it shovels what 100 sedans can't. Slower, yes, but more economical.

Mainframes are like that. They do data processing, not computing. They are the heirs of punch card processing. That's not only the reason why they are still around (and will be for quite some time), but also why there is no real need to port whole applications down to micros.

And much the same way that large lorries still fill our motorways, there is currently, and will be for the foreseeable future, a use case for modern mainframes - but that's a different story.


The Longer Story

Now, having said that, there was a need to port down parts of mainframe code down to micros: Compliance .

We all know that software is not simply some magic that does things, but codified business rules, regulations, and procedures. It formalizes judgement and decision making within a workflow, and there's a lot of that in companies. Where small companies may go along by some random, situation-based scheme, larger ones will have fine-tuned rules.

Let's take a simple one, checking an entry for validity, such as an order number for structure. With a decentralized client like in a car repair shop ordering spare parts, it would be cool to have the form beep already local when entering, not half an hour later when the logistics system returns a batch of error messages, right? It's a 25 character alphanumeric entry with lots of hyphens and alike. There is a precise rule on how to check it.

No issue, this can easily be done in C, right? Right, but there is already one module, written in COBOL, doing the check. And this one piece of source code is used (or called) wherever there is a part number check. Process management does not want anyone within the company to bypass that code.

So either the client developers fight an uphill battle for years to make their own implementation, or they somehow include that module. And that's exactly what the major use for mainframe originated COBOL on micros was, copying certain function to maintain compatibility and as a single source for validation and/or access.

Microsoft COBOL was quite up to the task of having a bunch of COBOL modules included in your PASCAL, C or BASIC program. Being limited to 64 KiB isn't a big deal, as such modules did not tend to be huge applications. Just closed/read-only source blobs to be compiled and called at the right time.

So long story short, it was (almost) never about porting whole applications down to micro, but integrating micros (as front ends) into a mainframe (software) environment.

Now, porting mainframe COBOL applications to UNIX on the other hand is a completely different story.

For completeness:

JCL, the job control language. Roughly equivalent to bash?

Err ... no, not really. Well, yes as it's about controlling jobs, but no so much as programming.

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?

Computing centers used a ton of JCL around every application. JCL is essentially the glue logic to transporting piles of punch cards between each stage of processing.Serious, you need to think of it as people moving carts between big mechanical card processing ... and later tapes and disk stacks :)

So no, JCL is not really an issue for COBOL on micros, as here handling is done different. CMD.EXE, PowerShell or BASH will be needed anyway - if at all.

RPG, the report generation language, going all the way back to 1959. Roughly equivalent to something like Crystal Reports, albeit without the GUI?

Just remotely. RPG isn't simply a report generator, but a full figured programming language. Its unique philosophy is again built around punch cards. RPG programs are essentially textual plugboards. Well, that's were it started out - nowadays it's way more complex.

Probably substantial chunks of a typical business application could be written in this?

Yes. If not all. Think of it as a framework for data shoveling.

But whoever had stuff written in RPG would have not migrated to PC but to a system /3x when downsizing. Lower software adaptation costs easily outweighs higher IBM mid range prices.

Also, if the previous system was a mainframe, then a micro would have been still too small to run it - not to mention that the PC is missing the integration.

DB2, a relational database. This actually seems less likely to be a problem, partly because it was first released only in 1983.

DB2 is SQL, and SQL is DB2. Literally.

IMS, a pre-relational database. This seems much more likely to be a problem.

IMS is more of an runtime environment and transaction system than a database. So transferring IMS application to a PC does not make much sense. What does make sense (a lot of sense, in fact) is doing client applications on micros from scratch, with no COBOL involved except maybe above-mentioned modules for compliance. IMS offered communication solutions again early on.

Other major software components that I'm not aware of?

CICS. Then again, for client usage, CICS connectors were available from early on, so no issue there, while server side interfaces weren't needed.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka
    Nov 25, 2020 at 10:50
  • 1
    Not sure how big this use case was in the overall COBOL-on-PC/microcomputer market - but Realia made a big deal of using an inexpensive, interactive, responsive PC as a development environment for programmer's targeting a mainframe. Realia COBOL was 100% IBM compatible (plus had certain features like ISAM files and even CICS) that made it an excellent way to code COBOL for mainframes - far better than any development environment IBM had. Build it on the PC, test locally, then ship it to the mainframe and compile and do final testing there. Raffzahn: any idea how much this was used?
    – davidbak
    Nov 6, 2021 at 17:54
  • 1
    @davidbak yes, and such use was quite a thing. After all, coding is an interactive process, and a supportive local environment improves processes a lot. I was a die hard terminal user all my life - or better als long as I was using our own IDE, which was a tight fit to our coding and testing process. But I did as well see and enjoy the advantage a local PC environment has over standard development processes on mainframes. So for other projects I did as well switch to PC use. Especially as supportive PC based IDEs became more capable during the 1990s, while mainframe based tools did not evolve
    – Raffzahn
    Nov 6, 2021 at 19:42
  • 1
    Ahhh, It sounds as if the practice to run JavaScript at both frontend and backend has an ancient root. BTW, wouldn't JCL cause significant overhead, as DOS batch always and Unix shell sometimes do when processing massive items?
    – Schezuk
    Nov 7, 2021 at 16:24
  • 1
    @Schezuk JCL does not handle data (well, usually not) but defines the environment for programs to run. Like assigning input and output files, requesting volumes, managing import or export to robot archives and so on. functions itself are done by OS commands or programs. From today's POV they are more like config and parameter fiels.
    – Raffzahn
    Nov 7, 2021 at 17:56

COBOL applications have not typically been ported from mainframes to micros because they rely on two features that micros typically lack.

  • Throughput COBOL applications often need to process large amounts of data in a fixed amount of time (e.g. processing a day's sales data for all stores in a chain). These tasks are typically I/O bound and mainframes have special hardware (e.g. I/O processors) to handle the load; micros don't have this.

  • Reliability Again, COBOL applications are often used in situations where downtime or errors cannot be tolerated. Mainframes have hardware and software redundancy built-in so that they can gracefully handle failures; micros typically don't have this.

See, for example, Tandem's NonStop platform.

Java (very popular for businesses) has been ported to a number of mainframe platforms. Even so, older applications are not typically rewritten since 1) they work fine as-is and 2) there is a risk of changing behavior (new bugs, etc.).

  • 3
    I'd suggest that they also rely on the operating system and "middleware". If a COBOL program is driven by events initiated by terminals and arriving on a queue, and if that infrastructure has never been reproduced adequately on anything smaller than a mainframe, then it's unlikely that the program will be migrated until events conspire to force it to be rewritten from scratch. Nov 24, 2020 at 14:47
  • 3
    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. Nov 24, 2020 at 15:19
  • 3
    Regarding reliability, I know of an installation where the main application was a COBOL port from a mainframe to an an iSeries (AS/400) with a bunch of middleware written in Java. The iSeries needs an IPL maybe once a year, whereas some of the JVMs get restarted every hour. Nov 24, 2020 at 18:03
  • 2
    @WildcatMatt My experience with Java on the AS/400 (stopped 6 years ago) was that the JVM (both classic and J9) was very robust. If the Java programs needed restarting, it was most likely due to memory/resource leaks in themselves, not the JVM's. I found, however, that the error handling in the jt400 library could not be relied on releasing all resources, so in case of any problem, the AS400Connection object had to be closed and discarded. Nov 24, 2020 at 19:48
  • 5
    @ThorbjørnRavnAndersen - I wrote the AS/400 JVM, with help from a half-dozen co-workers, working in Rochester, MN. As you state it was remarkably robust, as was the subsequent MAGIC MI translator (for translating from "old MI" to "new MI" for the iSeries machines), based on the same technology as the JVM translator.
    – Hot Licks
    Nov 24, 2020 at 23:54

Different things happened.

One, when mainframes were replaced, their applications were replaced with new applications written in modern languages for the new platforms. Many a IBM mainframe have been replaced by modern Unix machines with completely new software applications.

Two, for those that didn't want rewrite their applications, but change platforms, they relied on virtual environments to run the software. We installed a new HP replacing an IBM system, and part of the installation was a emulator to run IBM code on the HP. So, in this case, the sytem did not need to be rewritten.

The real question is why there was never much "greenfield" COBOL written on smaller machines. Likely this was just a matter of modern systems, modern environments, which had more value to the developers than COBOL could offer them at the time.

  • 3
    I know about several new (greenfield) projects, around 1980, using COBOL, but not on micros, but UNIX. In part as they were to be integrated in existing landscapes, but as well for downsizing projects - like applications that needed to serve only a dozend or so users, but relying heavy on custom code. A major reason for COBOL was the available infrastructure (and programmers).
    – Raffzahn
    Nov 24, 2020 at 14:49
  • 1
    That sounds really interesting! I'm curious what the emulator product was and how it was pulled off, would appreciate if you could say something about that? retrocomputing.stackexchange.com/questions/17064/…
    – rwallace
    Nov 25, 2020 at 3:54
  • 2
    There were a lot of Greenfield COBOLprojects in the 90's. The same way there were a lot of SAP/ABAP greenfield projects this century. The same way there are a lot of legacy .Net projects now. Moving to midrange AIX was not cheap, you still had to buy it, and the hardware. You could get scheduling going on downsized hardware too. But PC's are not built like the proverbial brick outhouse and required half a billion at the drop of a hat to migrate from CP/M to Xenix to OS/2 to Windows NT to Windows XP to Windows 7 to Windows 10. Sticking with 3270 for backroom was a winner for 25 years or so.
    – mckenzm
    Dec 27, 2021 at 21:31

Not sure what you really asked.

I was an IBM SE back then. Cobol is a compiled language. So you need a compiler for it. The compiler needs an operating system. The operating system needs a mainframe computer. The mainframe computer needs FEs to maintain it and electricity to run it and it needs to be cooled in a special room with a raised floor to permit cabling underneath.

There were many mainframes that ran cobol. There were several operating systems that ran cobol although only two main classes of those: Big Oz and Dos. Maybe s/20 had an opsys too with cobol. There were several compilers with various completeness of features. Again mostly DOS and OS based. Unsure about s/20 ; and later s/3 which I think was only RPG.

If you could ask a shorter direct question we could answer you better.

  • 4
    if you are going to downvote an answer you should at least give a reason
    – IBM SE
    Nov 25, 2020 at 22:41
  • 1
    Part of what I'm doing is acquiring enough understanding of how those systems worked, to be able to figure out more focused questions! I upvoted you for the interesting comments on multiple operating systems and compilers - there were several COBOL compilers? What was the purpose of this? Was it a matter of allowing customers to make trade-offs between feature completeness versus money spent on memory? Were the smaller compilers derived from the larger one, or written separately?
    – rwallace
    Nov 27, 2020 at 0:18
  • Possibly a reason for a downvote (though I didn't) is that this could reasonably be considered "not an answer". The "not sure what you really asked" and "if you could ask a shorter ..." texts may indicate it woulod be better as a comment to the question, seeking clarification.
    – paxdiablo
    Sep 5, 2023 at 0:00

What was the most critical supporting software for COBOL on IBM mainframes?

I'd venture to say that it was neither of the things you mention; I think it was what IBM termed "access methods" -- data structures and low level system libraries allowing programmatic access to files, first sequential (on tapes), later random (on DASDs). COBOL evolved to be pretty tightly integrated with the access methods available at each stage of its development (ISAM, VSAM, BDAM etc.)

A large portion of COBOL applications have been what we call today ETL jobs: reading files, parsing input records, manipulating them, the writing new files with a different record structure. SQL and interactive I/O capabilities were added to COBOL much later.

Minicomputer operating systems offered a different, higher-level abstraction for file access, which required new programming paradigms, languages and tools. By the time various COBOL implementations were ported to mini- and microcomputer platforms, the "native" alternatives had already had established themselves, bringing about a new generation of programmers and related technologies.


IMS is more of an runtime environment and transaction system than a data base.

I'll have to disagree on that one. IMS is/was a non-relational database (hierachical, if I correctly recall my grad school course in it). It's almost unused today, everyone having gone over to relational databases (SQL style).

Perhaps you were thinking of CMS (Conversational/Cambridge Monitor System) under VM, or TSO (Time Share Option, I think) under MVS?

  • Beside the fact,that RC.SE answers aren't a forum for discussions (that's what comments are for), you might at least want to add a reference to the answer you are commenting on.
    – Raffzahn
    Nov 24, 2020 at 15:54
  • 5
    No, IMS is still in wide use today and as well supported with new releases and functions. And no again, IMS is not just a database. The database part is IMS-DB, while the transaction system is IMS-DC. In fact, IMS can quite well be useful (and is widely used) without IMS-DB but other database engines and/or custom database designs.
    – Raffzahn
    Nov 24, 2020 at 16:00
  • 3
    Yeah, I worked on a huge IBM Mainframe COBOL project 30 years ago; no IMS-DB nor IMS-DC. And no DB2. Billing system for a large telecom. Pretty much flat files. Nov 24, 2020 at 21:55
  • 1
    Let's read about NoSQL.
    – Polluks
    Nov 25, 2020 at 7:47

The mainframe of yesterday is today’s micro eg: IBM’s Z series. As for today’s micros not having IO processors, it began with IDE drives. Even the cheapy SATA hard drives of today have significant cache and transfer rates that would leave the old mainframe systems standing. The average smartphone far exceeds the io and compute performance of 80’s mainframes. As for the cobol applications not being ported or replaced - I think that is referred to as ‘technical debt’

  • 6
    You deeply underestimate the performance of 1980's mainframes at the tasks they were built for. No, they didn't make video calls, but they slung data around quite well.
    – Jon Custer
    Nov 24, 2020 at 15:27
  • 2
    Name a mainframe then we can hopefully get some specs to confirm/deny. I’d be surprised if today’s SATA disk drive wouldn’t beat the pants off a 80’s vintage hard disk system both in peak and sustained data rate.
    – Kartman
    Nov 24, 2020 at 21:54
  • 3
    "The 3081 is capable of supporting up to 24 channels, which can be of either the byte-multiplexer or blockmultiplexer type. A maximum of four byte-multiplexer channels can be configured within the 3081 Processor Complex. All block-multiplexer channels have a datastreaming capability which permits data rates up to 3 megabytes per second per channel. Channels are assignable to two channel sets, one set for each central processor, with a maximum of 16 channels to a set." - all those available channels make a large difference for throwing data around.
    – Jon Custer
    Nov 25, 2020 at 0:09
  • 2
    For point of comparison, a ‘fast’ sdcard claims 80MB/s. The sdcard also does not have mechanical seek latency. At a rough estimate, the sd card is equivalent to around 26 mux channels of bandwidth. Then the average smartphone cpu along with memory bandwidth trumps even a multiprocessor 3081 class machine significantly. The mux channels probably had local memory mapped into the main cpu space to increase throughput. Whilst it is an unfair comparison of two machines of 35 years difference, i can’t see how the 3081 with a full complement of DASD could compete with the average smartphone of today
    – Kartman
    Nov 25, 2020 at 1:00
  • 1
    @UnslanderMonice. The average 'modern' business app is really no different the ones of old - how do you think the instruction mix from an old COBOL compiler would differ from what a modern cpu would see running a database app written in php, C++ etc? You don't need parallelism to keep the wide data paths full - if that were the case, then we'd not need cache memory. A single core is still faster than main memory. Multiple cores make the situation worse. I think it was Cray that said something like 'cache is no substitute for memory bandwidth'
    – Kartman
    Nov 28, 2020 at 2:09

You must log in to answer this question.

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