6 ms·

Cobol is still there not because of cobol itself, but because of vendor and platform lock-in. And I guess having monolithic codebase/platform. it’s not even es

Cobol is still there not because of cobol itself, but because of vendor and platform lock-in. And I guess having monolithic codebase/platform. it’s not even esoteric and difficult, just a lot of it without much structure visible to you.

danielmarkbruce 2y ago
This is what people miss about COBOL. It's not like people are compiling COBOL and running it on Linux on an x86 box. They are running it on legacy operating systems (and hardware) which provide a different set of underlying services. It's a whole different planet.
- Muromec 2y ago
  A different kind of cloud you can say.
  - danielmarkbruce 2y ago
    ha yes. There is actually a pretty cool product that is made by a division of Rocket Software named "AMC", it takes a COBOL app running on an IBM system and deploys it to a whole set of services on AWS. There are some smart dudes at that shop.
    - Muromec 2y ago
      Doesn't surprise me at all, somebody out there should be smart enough to make good money on that and not be very loud about it either.
- crackez 2y ago
  Negativo friendo. The mainframe is turning into a middleware layer running on Enterprise Linux. We've containerized the mainframe at this point, and I mean that directly - eg. Running jcl, multiple CICS regions, all in COBOL that originated on z/OS is now running in k8s on amd64.
  - danielmarkbruce 2y ago
    Yup, but the COBOL application doesn't know you've done that.
  - Muromec 2y ago
    There is a major drawback to this approach -- you need to have somebody who knows what they are doing. Total deal breaker in most of the places that have this problem in the first place.
    - gerdesj 2y ago
      "you need to have somebody who knows what they are doing" That applies everywhere. Your parent comment has managed to stuff a mainframe in a container and suddenly, hardware is no longer an issue. COBOL is well documented too so all good and so too will be the OS they are emulating. I used to look after a System 36 and I remember a creaking book shelf. The code base may have some issues but it will be well battle tested due to age. Its COBOL so it is legible and understandable, even by the cool kids. If you lack the skills to engage with something then, yes, there will be snags. If you are prepared to read specs, manuals and have some reasonable programing aptitude and so on then you will be golden. No need for geniuses, just conscientious hard workers. It's not rocket science.
      - Muromec 2y ago
        It's not the point I'm trying to make. Yes you can do fancy stuff like that and de-mainframing COBOL is to run in on k8s is the path I would personally choose if I had to deal with it. It sounds like a lot of fun and the sense of accomplishment to finally have it running should be great. The problem is -- it's very smart and unique, while organizations that have this kind of a problem don't want to depend on unique set of skills of a few highly capable individuals. Everything needs to be boring and people have to be replaceable. In this paradigm, vendor java with aws lock-in is a cost, but in-house fancy stuff with cobol on k4s done by smart people in house is worse -- it's a risk.
      - SonOfLilit 2y ago
- WesleyJohnson 2y ago
  We're running RM/COBOL on RHEL8 VMs backed powered by VMware. I don't work with it, I'm in a different IT area, but our COBOL codebase supports the lion's share of our day-to-day operations.
jklowden 2y ago
COBOL is still running where it’s running because those old applications 1) work and 2) are very expensive to rewrite. Unimportant programs were abandoned. Simple one were migrated to Java decades ago. The useful-and-complicated — and often badly designed — are what remain. If you’re a bank, you run COBOL. Estimates are 95% of ATM transactions go through a COBOL program. But it doesn’t have to run on a mainframe! We’re adding COBOL to the GNU Compiler Collection. www.cobolworx.com.

danielmarkbruce 2y ago

This is what people miss about COBOL. It's not like people are compiling COBOL and running it on Linux on an x86 box. They are running it on legacy operating systems (and hardware) which provide a different set of underlying services. It's a whole different planet.

Muromec 2y ago
A different kind of cloud you can say.
- danielmarkbruce 2y ago
  ha yes. There is actually a pretty cool product that is made by a division of Rocket Software named "AMC", it takes a COBOL app running on an IBM system and deploys it to a whole set of services on AWS. There are some smart dudes at that shop.
  - Muromec 2y ago
    Doesn't surprise me at all, somebody out there should be smart enough to make good money on that and not be very loud about it either.
crackez 2y ago
Negativo friendo. The mainframe is turning into a middleware layer running on Enterprise Linux. We've containerized the mainframe at this point, and I mean that directly - eg. Running jcl, multiple CICS regions, all in COBOL that originated on z/OS is now running in k8s on amd64.
- danielmarkbruce 2y ago
  Yup, but the COBOL application doesn't know you've done that.
- Muromec 2y ago
  There is a major drawback to this approach -- you need to have somebody who knows what they are doing. Total deal breaker in most of the places that have this problem in the first place.
  - gerdesj 2y ago
    "you need to have somebody who knows what they are doing" That applies everywhere. Your parent comment has managed to stuff a mainframe in a container and suddenly, hardware is no longer an issue. COBOL is well documented too so all good and so too will be the OS they are emulating. I used to look after a System 36 and I remember a creaking book shelf. The code base may have some issues but it will be well battle tested due to age. Its COBOL so it is legible and understandable, even by the cool kids. If you lack the skills to engage with something then, yes, there will be snags. If you are prepared to read specs, manuals and have some reasonable programing aptitude and so on then you will be golden. No need for geniuses, just conscientious hard workers. It's not rocket science.
    - Muromec 2y ago
      It's not the point I'm trying to make. Yes you can do fancy stuff like that and de-mainframing COBOL is to run in on k8s is the path I would personally choose if I had to deal with it. It sounds like a lot of fun and the sense of accomplishment to finally have it running should be great. The problem is -- it's very smart and unique, while organizations that have this kind of a problem don't want to depend on unique set of skills of a few highly capable individuals. Everything needs to be boring and people have to be replaceable. In this paradigm, vendor java with aws lock-in is a cost, but in-house fancy stuff with cobol on k4s done by smart people in house is worse -- it's a risk.
    - SonOfLilit 2y ago
WesleyJohnson 2y ago
We're running RM/COBOL on RHEL8 VMs backed powered by VMware. I don't work with it, I'm in a different IT area, but our COBOL codebase supports the lion's share of our day-to-day operations.

jklowden 2y ago

COBOL is still running where it’s running because those old applications 1) work and 2) are very expensive to rewrite. Unimportant programs were abandoned. Simple one were migrated to Java decades ago. The useful-and-complicated — and often badly designed — are what remain. If you’re a bank, you run COBOL. Estimates are 95% of ATM transactions go through a COBOL program. But it doesn’t have to run on a mainframe! We’re adding COBOL to the GNU Compiler Collection. www.cobolworx.com.