A GCC COBOL status report

Posted Feb 11, 2023 8:46 UTC (Sat) by Wol (subscriber, #4433)
In reply to: A GCC COBOL status report by vasvir
Parent article: A GCC COBOL status report

> So this looks like something trivial to implement. Is there any hidden gotchas that my untrained eye didn't spot? or this is difficult because COBOL is not cool and there are no enthusiasts to hack on a compiler for it?

Probably this.

If the user and dev communities are the same, open source of one form or another flourishes. As soon as the user and dev communities diverge, like eg word processors (real programmers use TeX, Sphinx, etc not mere word processors), then open source struggles.

And COBOL is seen as horribly verbose and not pleasant to work with. Features that also, I believe, lead to its reliability because you have to specify everything ...

Cheers,
Wol

A GCC COBOL status report

Posted Feb 11, 2023 14:05 UTC (Sat) by joib (subscriber, #8541) [Link] (2 responses)

Disclaimer: I've never used COBOL myself and I don't work in the field.

An addition to the user and dev communities being distinct, I think there's a couple other factors making open source COBOL difficult:

- COBOL typically runs on a mainframe that comes with a support contract and an officially supported compiler, so little incentive to work on a FOSS compiler.

- The applications are typically bespoke in-house applications tailored to each organization. So you don't get megacompany X putting their payroll processing system up on GitHub, and suddenly COBOL programmers around the world descend on it and start improving it, so that anyone can download it and start doing payrolls for their company with it.

I guess the niche where Gnu COBOL could make an impact would be in migrations from a mainframe environment to a 'standard' Linux system, possibly even in the cloud.

A GCC COBOL status report

Posted Feb 13, 2023 21:15 UTC (Mon) by skissane (subscriber, #38675) [Link] (1 responses)

> COBOL typically runs on a mainframe that comes with a support contract and an officially supported compiler, so little incentive to work on a FOSS compiler.

There's a lot of COBOL apps out there that don't run on mainframes. Micro Focus' COBOL products for Windows and Unix go back a long way – in the late 1970s thru early-mid 1990s, Microsoft rebadged Micro Focus' COBOL products for CP/M, DOS, OS/2 and Windows 3.x as "Microsoft COBOL", and IBM similarly offered a rebadged Micro Focus as "IBM COBOL" for PC-DOS. Some of these apps started life out on a mainframe or minicomputer, but were ported off decades ago, and are still alive; others were written to run on a PC platform to begin with. Imagine it is 1985, and you are an MIS manager at some bank, and you manage a room full of mainframe COBOL programmers, and you want to get them started on writing some apps to run on PCs – a COBOL compiler for DOS would be an easy sale. And maybe, close to 40 years later, one of those DOS COBOL apps is still in use, running on Windows or even Linux, with an expensive Micro Focus COBOL runtime license (they don't just license the development tools on a per-seat basis, they do that for the runtime too.) Recompiling it with an open-source COBOL compiler, ditching the need to keep on paying those licensing costs, may have a certain attraction.

A GCC COBOL status report

Posted Feb 27, 2023 21:18 UTC (Mon) by nix (subscriber, #2304) [Link]

Aside: COBOL is really Micro Focus's strength (they've been doing it forever, like since before the 80s, they're older than Oracle and even less sexy), but they were also long known as the place old tired companies went to die: Borland, CompuWare, Novell... when they accidentally got hold of something actually exciting they got rid of it (SuSE).

As usual for the UK we couldn't hold on to it after the political excitements of the last few years (and the rollercoastering pound): the company has just been purchased by OpenText, a Canadian company only slightly more exciting than Micro Focus. I can't really imagine them changing much.