<story><title>20 Years in the Making, GnuCOBOL Is Ready for Industry</title><url>https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/</url></story><parent_chain><item><author>ajxs</author><text>I&amp;#x27;ve spent some time working in finance, so I&amp;#x27;ve actually worked with COBOL developers personally in multiple different roles. In all those cases they were maintaining legacy applications that ran on IBM mainframes. Why would a company choose to use COBOL if they weren&amp;#x27;t restricted to what ran on IBM&amp;#x27;s mainframe infrastructure? Serious question, not an attack.&lt;p&gt;I get that many of these legacy applications are some of the most battle-tested things in existence, and do what they do very well. I&amp;#x27;ve seen them in action personally. However I&amp;#x27;m also under the impression that COBOL is just not that amazing compared with modern alternatives: It&amp;#x27;s not easy to write, or maintain, and (as far as I understand) the things that make it &amp;#x27;fast&amp;#x27; have more to do with the platform than COBOL itself.&lt;p&gt;I&amp;#x27;d love to know more about why someone would choose COBOL today, if anyone can fill me in.</text></item><item><author>NikolaNovak</author><text>&amp;gt;&amp;gt;Get those punch cards back out!&lt;p&gt;I get that&amp;#x27;s (probably!) a joke, but it misrepresents COBOL as something &lt;i&gt;completely&lt;/i&gt; stuck in the 70s. And, y&amp;#x27;know, it isn&amp;#x27;t exactly the fanciest language in the world, but we still have several programmers on our project and they&amp;#x27;re spitting out new code every day of their life, no punchcards:).&lt;p&gt;(And it&amp;#x27;s not on a mainframe either - it&amp;#x27;s running primarily on AIX, with some of Windows and Linux).</text></item></parent_chain><comment><author>skissane</author><text>&amp;gt; I&amp;#x27;d love to know more about why someone would choose COBOL today, if anyone can fill me in.&lt;p&gt;I doubt anybody is choosing to start a new greenfield system in COBOL in 2024.&lt;p&gt;But, if you have an existing COBOL code base, and the business is asking for new features, you have two basic choices (1) write new modules for the existing system in COBOL (2) write the new modules in a more mainstream language (Java, C#, whatever) and have the existing COBOL modules integrate with those new modules (e.g. using REST)&lt;p&gt;Both options have their pros and cons. If you aren&amp;#x27;t already doing (2), then (in the short-term at least) (1) is the easier path.</text></comment>
<story><title>20 Years in the Making, GnuCOBOL Is Ready for Industry</title><url>https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/</url></story><parent_chain><item><author>ajxs</author><text>I&amp;#x27;ve spent some time working in finance, so I&amp;#x27;ve actually worked with COBOL developers personally in multiple different roles. In all those cases they were maintaining legacy applications that ran on IBM mainframes. Why would a company choose to use COBOL if they weren&amp;#x27;t restricted to what ran on IBM&amp;#x27;s mainframe infrastructure? Serious question, not an attack.&lt;p&gt;I get that many of these legacy applications are some of the most battle-tested things in existence, and do what they do very well. I&amp;#x27;ve seen them in action personally. However I&amp;#x27;m also under the impression that COBOL is just not that amazing compared with modern alternatives: It&amp;#x27;s not easy to write, or maintain, and (as far as I understand) the things that make it &amp;#x27;fast&amp;#x27; have more to do with the platform than COBOL itself.&lt;p&gt;I&amp;#x27;d love to know more about why someone would choose COBOL today, if anyone can fill me in.</text></item><item><author>NikolaNovak</author><text>&amp;gt;&amp;gt;Get those punch cards back out!&lt;p&gt;I get that&amp;#x27;s (probably!) a joke, but it misrepresents COBOL as something &lt;i&gt;completely&lt;/i&gt; stuck in the 70s. And, y&amp;#x27;know, it isn&amp;#x27;t exactly the fanciest language in the world, but we still have several programmers on our project and they&amp;#x27;re spitting out new code every day of their life, no punchcards:).&lt;p&gt;(And it&amp;#x27;s not on a mainframe either - it&amp;#x27;s running primarily on AIX, with some of Windows and Linux).</text></item></parent_chain><comment><author>chasil</author><text>We actually rely upon two different operating environments for COBOL that do not originate from IBM.&lt;p&gt;The first is OS2200. Our final major application on this platform was complete by 1970, and links COBOL into assembler that accesses the hierarchical DMS database. The first SMP port of UNIX was to this hardware:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;OS_2200&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;OS_2200&lt;/a&gt;&lt;p&gt;The second is VMS, specifically the VAX variety. VMS bundled a COBOL compiler, which we used to write ACMS applications.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;OpenVMS&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;OpenVMS&lt;/a&gt;&lt;p&gt;We continue to produce new COBOL code for both.</text></comment>