5 ms·

Unlike Fortran, COBOL really hasn't evolved in the C dominated world. Although C is really dominant on the platforms COBOL lives on.

pjmlp 6y ago
What?!? Cobol has had its last revision in 2014, supports modules, OOP, and even has .NET and JVM backends. MicroFocus and Fujistsu also have frameworks for cloud deployments and writing microservices in Cobol. Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor.
- protomyth 6y ago
  That's basically it, no one cares about C on the mainframe so COBOL doesn't deal with the C competition and C flaws that fuel Go and Rust. COBOL itself has advanced but it doesn't have the same competition.
  - pjmlp 6y ago
    They don't care about C because mainframes always had better alternatives for systems programming, via PL/S, PL.8 and NEWP, as the three major surviving ones. Even BLISS and Mesa were better than C.
    - protomyth 6y ago
      If I remember correctly OpenVMS was programmed in something else also. It would have been interesting if one of the PC operating systems had decided to use one of those languages. So, no C, no interest in 'I need a C replacement language', enterprise software is boring, so no COBOL replacement. Plus, I know of at least one vendor who did develop something but it is kept in-house. I did expect someone to develop yet another REXX to address this need.
- skissane 6y ago
  > Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor. I think, with Metal C, that's less true than it used to be. My understanding is that, for brand new z/OS components (e.g. Zowe, z/OSMF), IBM prefers Metal C to PL/X. It is also seeing increasing use by mainframe ISVs as a replacement for assembly and PL/X.
  - pjmlp 6y ago
    IBM uses mostly C++ alongside PL/S, Metal C is a niche solution, most users are supposed to target the language environments.
    - skissane 6y ago
      For low level stuff, you can’t use the language environment. Assembler, PL/X and Metal C work fine without the language environment, C++ requires it.
      - pjmlp 6y ago
        And unless one is an IBM employee on IBM i team or driver writer for IBM i, there isn't really a sound reason to use it, hence niche.
        skissane 6y ago
        Metal C is for z/OS, not IBM i. ISVs definitely use it, not just IBM. Most z/OS user exits cannot use language environment, they must use either Metal C, assembly or PL/X. (And, outside of IBM, PL/X is only an option for those few companies who have bought PL/X licenses, which apparently IBM doesn’t even sell anymore.) Also, historically there has been a big culture at z/OS sites of writing site-specific user exits in assembly. Less of a need for it nowadays given features in newer z/OS versions and ISV solutions, but some folks still do it. And Metal C is the only alternative to assembly that customers have. For a real world example of where it is used, I used to work with a product that used RACF user exits to send security change notifications over the network to a Java app running on a Unix system, for auditing, scheduled access certification, etc. (The user exit in question was written in HLASM not Metal C, but if you were building the same thing from scratch today you’d quite possibly choose Metal C over HLASM. You can’t write a RACF user exit in C++ because that needs language environment and language environment use is not allowed in RACF user exits.)

pjmlp 6y ago

What?!? Cobol has had its last revision in 2014, supports modules, OOP, and even has .NET and JVM backends. MicroFocus and Fujistsu also have frameworks for cloud deployments and writing microservices in Cobol. Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor.

protomyth 6y ago
That's basically it, no one cares about C on the mainframe so COBOL doesn't deal with the C competition and C flaws that fuel Go and Rust. COBOL itself has advanced but it doesn't have the same competition.
- pjmlp 6y ago
  They don't care about C because mainframes always had better alternatives for systems programming, via PL/S, PL.8 and NEWP, as the three major surviving ones. Even BLISS and Mesa were better than C.
  - protomyth 6y ago
    If I remember correctly OpenVMS was programmed in something else also. It would have been interesting if one of the PC operating systems had decided to use one of those languages. So, no C, no interest in 'I need a C replacement language', enterprise software is boring, so no COBOL replacement. Plus, I know of at least one vendor who did develop something but it is kept in-house. I did expect someone to develop yet another REXX to address this need.
skissane 6y ago
> Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor. I think, with Metal C, that's less true than it used to be. My understanding is that, for brand new z/OS components (e.g. Zowe, z/OSMF), IBM prefers Metal C to PL/X. It is also seeing increasing use by mainframe ISVs as a replacement for assembly and PL/X.
- pjmlp 6y ago
  IBM uses mostly C++ alongside PL/S, Metal C is a niche solution, most users are supposed to target the language environments.
  - skissane 6y ago
    For low level stuff, you can’t use the language environment. Assembler, PL/X and Metal C work fine without the language environment, C++ requires it.
    - pjmlp 6y ago
      And unless one is an IBM employee on IBM i team or driver writer for IBM i, there isn't really a sound reason to use it, hence niche.
      - skissane 6y ago
        Metal C is for z/OS, not IBM i. ISVs definitely use it, not just IBM. Most z/OS user exits cannot use language environment, they must use either Metal C, assembly or PL/X. (And, outside of IBM, PL/X is only an option for those few companies who have bought PL/X licenses, which apparently IBM doesn’t even sell anymore.) Also, historically there has been a big culture at z/OS sites of writing site-specific user exits in assembly. Less of a need for it nowadays given features in newer z/OS versions and ISV solutions, but some folks still do it. And Metal C is the only alternative to assembly that customers have. For a real world example of where it is used, I used to work with a product that used RACF user exits to send security change notifications over the network to a Java app running on a Unix system, for auditing, scheduled access certification, etc. (The user exit in question was written in HLASM not Metal C, but if you were building the same thing from scratch today you’d quite possibly choose Metal C over HLASM. You can’t write a RACF user exit in C++ because that needs language environment and language environment use is not allowed in RACF user exits.)