Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

COBOL: Thinking about it wrong

gcn.com

Post reply on HN
Print view View original

31–40 of 116 posts

Re: COBOL: Thinking about it wrong

#31

Post by YeGoblynQueenne »

VulgarExigency wrote: post #21
bitwize wrote: post #10

Earlier quoted context omitted.

> How much COBOL code can run on a regular Ubuntu machine? All of it. GNU Cobol exists, as do proprietary solutions from companies like Micro Focus that target the JVM and .NET (which is what you're looking for for a real COBOL solution). But why is it so important to run COBOL on Ubuntu? If you need Linux, create a Linux LPAR on your mainframe. > What's the package manager for OSS packages? COBOL code runs Western c…

There are several programming languages with package managers that work better than NPM. Not having one is not a positive no matter how you try to spin it.

What exactly would you package manage if you had a package manager for COBOL? You will never get paid to work on any COBOL code that isn't proprietary, and sealed with the blood of innocent victims. You are not going to be installing the latest hot js framework on a mainframe.

Re: COBOL: Thinking about it wrong

#32

Post by GartzenDeHaes »

mattnewton wrote: post #15

I have never written cobol, but I wonder if there is a market for a COBOL transpiler to something like C#/Java/typescript, or even python would be a viable business?

There are companies that specialize in this area such as Microfocus and Fujitsu.

A long time ago, I wrote a Tandem COBOL to C# and WPF translator (https://github.com/GartzenDeHaes/cobol2cs). The key bits are:

- COBOL UI's run in a customer written environment that provides security, navigation, and session data. In the system that I wrote, there's a WPF application that provides these services.

- Convert SCREEN COBOL to C#. The Tandem uses a VT6530 that is similar to an extended IBM 3270. There are client-side protected fields and scrollable areas that need to be emulated in WPF.

- Convert COBOL servers to C#. The Tandem has a 3-tier architecture where the screen programs talk to services running in a middle tier through an network layer called PATHWAY. These can be converted to classes and be created on demand in C#.

- Remote access to SQL/MP databases. Tandem has a Java Servlet environment that can be used as a data access layer. The transpiler generates these Servlets and the C# data access layer.

Re: COBOL: Thinking about it wrong

#33

Post by guestbest »

7thaccount wrote: post #26
benjaminpv wrote: post #13

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news. 'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the h…

It's the same reason why I opted to spend only minimum time with the dying tech in my old role and find something more broadly applicable. You're super important until you're not, so general tech that is useful in many areas is a lot safer. Cobol ain't going away anytime soon, but it certainly might limit what jobs you can get other places depending on the hiring algorithm.

Even important people aren’t compensated based on their importance but their marketability. Also, pay is usually just enough to prevent employees from leaving to a competing jobs. Too much institutional knowledge can ironically leave an employee uncompetitive in the market.

Re: COBOL: Thinking about it wrong

#34

Post by JohnFen »

yobbo wrote: post #16
mattnewton wrote: post #15

I have never written cobol, but I wonder if there is a market for a COBOL transpiler to something like C#/Java/typescript, or even python would be a viable business?

I suspect it's not the language itself but the systems already in place. Transpiling to something else wouldn't help.

Yes. I know of companies that run mainframe emulators purely to keep using the existing COBOL codebase that was written for them.

They go to that level of weirdness because replacing the existing codebase would not only be much more expensive, but would introduce a great deal of risk that they aren't willing to take on.

A transpiler would not really address the needs of that sort of company.

Re: COBOL: Thinking about it wrong

#35

Post by hiAndrewQuinn »

How would one even go about finding opportunities to program COBOL professionally? I feel like I'd actually go for it if I was able to do it remote, but mainframes conjure up this image for me of sitting next to a tiny green terminal somewhere deep underground, leashed to The Beast or Blue Giant or some other whimsically-named thing.

Re: COBOL: Thinking about it wrong

#36

Post by BlandDuck »

I have seen the COBOL issue come up a number of times, and I just don't get it. Am I thinking about this wrong?

COBOL seems to be a straightforward language by modern standards. Any programmer with experience with imperative languages should be able to pick it up. Learning the language itself cannot be a real barrier.

The barrier seems to be the enormous amount of legacy code that has to be digested and understood. But wouldn't that barrier be pretty much the same regardless of the programming language. I mean, if it were 800 billion lines of Perl code, would that make the problem any easier?

So isn't the real problem that we have 800 billion lines of legacy code that needs to be understood and maintained; it just happens to be written in COBOL?

Re: COBOL: Thinking about it wrong

#37

Post by kjs3 »

3pt14159 wrote: post #18
W-Stool wrote: post #6

People that have not been exposed to legacy industries (banking, insurance, etc) would simply not believe how many of these large/huge companies run the majority of their business on an IBM mainframe running COBOL code. I've seen it firsthand and I didn't believe it. For them, it just works.

I would argue that, despite the design failures, more of modern society runs on JavaScript. I know that it is hard to accept, but a crappy piece of ten year old JS with JQuery submitting a basic XHR request to a server to book a seat on an airplane or at a show matters just as much as your insurance operation that squeezes out a fraction of a point of return for an insurance package. We live in a world where many of…

book a seat on an airplane

The web site might be JS, but actually booking the seat is in all likelihood going through PARS/IPARS. Which runs on an IBM mainframe.

Re: COBOL: Thinking about it wrong

#38

Post by heisenbit »

1) popup

2) only opinion no meat

3) paper pointed to is a one pager with stats incl. numbers from stackoverflow

Not saying that there is not an argument to be made that the Cobol/Mainfram approach has it advantages. It is a straight jacket but some applications are really efficient compared with what is done these days.

Re: COBOL: Thinking about it wrong

#40

Post by aeschinder »

In the 1980s, COBOL was taught in my computer database class. I actually used my COBOL skills at the federal government Veteran's Affairs job I had for several years after college.

If you are always chasing the latest language and get high on syntactic sugar, you are likely going to be a problem for management if you work at an IT shop because you'll be writing important one-off programs in various languages that people after you will be required to support or rewrite.

John Carmack wanted to hire only C++ devs when he was at Oculus but had to relent and hire JavaScipt bros because of Meta.

TCO isn't just a question on your business class exam.

Post reply on HN