[HN Gopher] 20 Years in the Making, GnuCOBOL Is Ready for Industry
       ___________________________________________________________________
        
       20 Years in the Making, GnuCOBOL Is Ready for Industry
        
       Author : cglong
       Score  : 66 points
       Date   : 2024-03-16 19:02 UTC (3 hours ago)
        
 (HTM) web link (thenewstack.io)
 (TXT) w3m dump (thenewstack.io)
        
       | ddgflorida wrote:
       | Well that's exciting :)
        
       | proneb1rd wrote:
       | Very exotic. Does it support multi threading? What kind of things
       | can be done with it?
        
         | foobarian wrote:
         | I'm guessing it does money math in a certain way vetted by this
         | field that would be very difficult to recertify on some
         | replacement.
        
           | airstrike wrote:
           | For some value of "very difficult"
        
       | seanhunter wrote:
       | But you need a modern enterprise-quality framework. Can it run
       | Cobol on Cogs?
       | 
       | http://www.coboloncogs.org/INDEX.HTM
        
       | fredsmith219 wrote:
       | The vast majority of COBOL in production runs on IBM mainframes
       | in conjunction with JCL (Job Control Language). If you are
       | looking to offload COBOL from a mainframe to a cheaper platform
       | JCL is a must. I love that this project exists but it's only one
       | half of a solution to migration off of a mainframe.
        
         | macintux wrote:
         | I'm unfamiliar with JCL, but from a quick search it sounds like
         | most scripts don't use much of the language. Still, I'd bet
         | that most of the JCL functionality is used if you look at a
         | decent-sized collection of scripts.
         | 
         | How much of the full JCL do you think would be necessary to
         | reimplement in order to get, say, 30% of the existing scripts
         | to work?
        
           | smackeyacky wrote:
           | From memory of working with mainframe programmers back in the
           | 1990s, it isn't just JCL you need. Cobol programs typically
           | used databases and transaction monitors as well.
           | 
           | If you're lucky the database will be one of IBM's SQL
           | databases. If you're unlucky it will be something like IMS.
        
         | guestbest wrote:
         | Talking with mainframe guys for the last half decade, they seem
         | to avoid JCL when they can and treat REXX like a super power.
        
       | NikolaNovak wrote:
       | >>Get those punch cards back out!
       | 
       | I get that's (probably!) a joke, but it misrepresents COBOL as
       | something _completely_ stuck in the 70s. And, y 'know, it isn't
       | exactly the fanciest language in the world, but we still have
       | several programmers on our project and they're spitting out new
       | code every day of their life, no punchcards:).
       | 
       | (And it's not on a mainframe either - it's running primarily on
       | AIX, with some of Windows and Linux).
        
         | airstrike wrote:
         | Let us join hands in a moment of silent prayer for those
         | unfortunate souls
        
         | ajxs wrote:
         | I've spent some time working in finance, so I'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't restricted to what ran on
         | IBM's mainframe infrastructure? Serious question, not an
         | attack.
         | 
         | 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've seen them in action personally. However I'm
         | also under the impression that COBOL is just not that amazing
         | compared with modern alternatives: It's not easy to write, or
         | maintain, and (as far as I understand) the things that make it
         | 'fast' have more to do with the platform than COBOL itself.
         | 
         | I'd love to know more about why someone would choose COBOL
         | today, if anyone can fill me in.
        
           | santoshalper wrote:
           | Nobody chooses COBOL as a language for creating new systems
           | today. It is maintenance of existing systems, primarily but
           | not exclusively, running on IBM mainframe and midrange
           | servers.
        
           | chasil wrote:
           | We actually rely upon two different operating environments
           | for COBOL that do not originate from IBM.
           | 
           | 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:
           | 
           | https://en.m.wikipedia.org/wiki/OS_2200
           | 
           | The second is VMS, specifically the VAX variety. VMS bundled
           | a COBOL compiler, which we used to write ACMS applications.
           | 
           | https://en.m.wikipedia.org/wiki/OpenVMS
           | 
           | We continue to produce new COBOL code for both.
        
             | _huayra_ wrote:
             | Are you able to find COBOL programmers to hire, or is it
             | like Rust where a lot of jobs are "know C++ and we'll train
             | you"?
        
         | stevenally wrote:
         | COBOL is my next career move. I'm tired of these modern
         | languages.
        
       | rhaps0dy wrote:
       | > the past three years, it has received attention from 13
       | contributors with 460 commits.
       | 
       | That doesn't sound like very many commits. Pretty mature!
        
       ___________________________________________________________________
       (page generated 2024-03-16 23:00 UTC)