Live data from Hacker News

COBOL: Thinking about it wrong

gcn.com

101–110 of 116 posts

Re: COBOL: Thinking about it wrong

#101
post #46

Earlier quoted context omitted.

It's the same problem z/OS has: There's no hobbyist community so it remains obscure. Yes, you can run 1980s-era System/370 software under Hercules, but IBM keeps anything remotely modern under lock and key even though you'd think it would benefit IBM to have people indoctrinate themselves into the Blue Worldview.

It might not be legal, but it isn't hard to find newer versions to download if you know where to look – z/OS 1.11 is floating around, it is from 2009, so still rather old, but a lot newer than the 1970s. Also you can find some OS/390 and MVS/ESA versions from before that (1990s vintage). If someone privately runs it for purely non-commercial purposes – I myself never have, but some people do – I think it is rather un…

Can confirm. When I was experimenting with Hercules, I found z/OS 1.1.something easily.

Never got it installed, but yeah, it's easy enough to find.

Re: COBOL: Thinking about it wrong

#102

Earlier quoted context omitted.

Yeah it was over 30 years ago. I’m sure with more experience it might have been easier conceptually. I didn’t have any trouble with COBOL but found the whole mainframe environment to be rigid, crusty, and difficult to understand and use compared to the Unix systems I had used in school.

I don't understand the need for "mainframes" in industries such as banking. Isn't a mainframe just a beefy server? I get that 40 years ago it made sense for a bank processing thousands of transactions per day to have a big computer to do that. But today that could be done on a laptop with a Python script. Has the compute needs really grown proportional to the speedup of the hardware?

Weeeellll... yes and no. You aren't wrong, but I would just note that mainframes were remarkably reliable. They pushed a lot of boundaries on things that we still kinda struggle with today in terms of data integrity, redundancy, hot-swapability, recovery, etc. No question that today's systems are faster and perhaps in some ways more affordable. Definitely the case that the average person wanting to learn about software has more resources and tools available that once upon a time required access to these multi-million dollar machines. But, there's definitely tradeoffs between those centralized systems and our distributed systems of today.

Re: COBOL: Thinking about it wrong

#103

Earlier quoted context omitted.

Yeah it was over 30 years ago. I’m sure with more experience it might have been easier conceptually. I didn’t have any trouble with COBOL but found the whole mainframe environment to be rigid, crusty, and difficult to understand and use compared to the Unix systems I had used in school.

I don't understand the need for "mainframes" in industries such as banking. Isn't a mainframe just a beefy server? I get that 40 years ago it made sense for a bank processing thousands of transactions per day to have a big computer to do that. But today that could be done on a laptop with a Python script. Has the compute needs really grown proportional to the speedup of the hardware?

No they are not just beefy servers. Their raw processing power is not remarkable. They are built for throughput. I/O and peripherals are handled by separate hardware so the CPU only deals with data in memory. They also have more sophisticated virtualization and scalability features than standard servers or PCs.

https://en.m.wikipedia.org/wiki/Mainframe_computer

Re: COBOL: Thinking about it wrong

#104
post #46

Earlier quoted context omitted.

It's the same problem z/OS has: There's no hobbyist community so it remains obscure. Yes, you can run 1980s-era System/370 software under Hercules, but IBM keeps anything remotely modern under lock and key even though you'd think it would benefit IBM to have people indoctrinate themselves into the Blue Worldview.

It might not be legal, but it isn't hard to find newer versions to download if you know where to look – z/OS 1.11 is floating around, it is from 2009, so still rather old, but a lot newer than the 1970s. Also you can find some OS/390 and MVS/ESA versions from before that (1990s vintage). If someone privately runs it for purely non-commercial purposes – I myself never have, but some people do – I think it is rather un…

What are the advantages of these mainframe systems versus a basic Linux server?

Re: COBOL: Thinking about it wrong

#105
post #7

I'm pretty sure I'm thinking about it right. How much COBOL code can run on a regular Ubuntu machine? What's the package manager for OSS packages? What test frameworks are in common use? You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.

I assume GnuCOBOL can run on GNU/Linux. https://gnucobol.sourceforge.io/

That’s not really the same thing is it, though? I’m sure you can write new COBOL programs using it, but the challenge is the old ones. And for a million reasons, they’re tied to big iron.

It’s part of the fabric of our society, but it’s still a pain to work with.

Re: COBOL: Thinking about it wrong

#106
post #70
post #7

I'm pretty sure I'm thinking about it right. How much COBOL code can run on a regular Ubuntu machine? What's the package manager for OSS packages? What test frameworks are in common use? You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.

That would be like claiming PowerShell is irrelevant because it is not on the typical Ubuntu machine. While it is irrelevant to the typical Ubuntu user, the world is a diverse place and computing is no exception. That being said, I feel that the article made very weak arguments so I don't blame anyone for perpetuating the stereotypes. These are things such as mentioning which industries it is used in, but not being s…

I mean, I take your point, but Powershell is actually pretty easy to run on Ubuntu. The catch with most real COBOL is that it’s fundamentally entangled with big iron.

Re: COBOL: Thinking about it wrong

#107

Earlier quoted context omitted.

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 .

I know you’re attacking my point but I think you’re actually agreeing here. COBOL is tied to proprietary stuff running on big iron, and its claims to modernity are window dressing.

Re: COBOL: Thinking about it wrong

#108
post #10
post #7

I'm pretty sure I'm thinking about it right. How much COBOL code can run on a regular Ubuntu machine? What's the package manager for OSS packages? What test frameworks are in common use? You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.

> 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…

Honestly I picked Ubuntu at random. My point is there’s something intrinsically old school about something being tied to expensive proprietary hardware and while that remains true, it’s still a (possibly very lucrative) cul de sac.

I’m pretty bullish about the importance of COBOL, but while I have a lot of respect for the people working with it right now, it’s not something I’d recommend to someone at the start of their career.

Re: COBOL: Thinking about it wrong

#109

Earlier quoted context omitted.

It might not be legal, but it isn't hard to find newer versions to download if you know where to look – z/OS 1.11 is floating around, it is from 2009, so still rather old, but a lot newer than the 1970s. Also you can find some OS/390 and MVS/ESA versions from before that (1990s vintage). If someone privately runs it for purely non-commercial purposes – I myself never have, but some people do – I think it is rather un…

What are the advantages of these mainframe systems versus a basic Linux server?

Backward compatibility. In 1970, you buy an IBM mainframe and start writing apps to run on it. In 2023, you are still running the same code base - albeit with innumerable enhancements and fixes over the ensuing decades. On an IBM mainframe, that code base will just work. On Linux, it won’t even run - unless you buy some expensive mainframe rehosting package, which is full of gaps and limitations, and may introduce obscure bugs which the original lacked.

Reliability - most large-scale Linux systems are based on a distributed model - the app runs on a cluster containing dozens/hundreds/thousands of servers, if a single server has a hardware fault, the app just keeps on working and at worst some user might get an error which goes away if they retry. So, no point in spending $$$$ to maximise the reliability of any individual node.

By contrast, many mainframe customers have just one mainframe, and if it breaks they go down - which means the mainframe hardware has to be super-reliable, filled with redundancy, error detection/recovery, etc - and you pay $$$$ for all that redundancy.

IBM mainframes can be clustered - e.g. z/OS Parallel Sysplex - but only the largest sites do that. The maximum supported cluster size is 32 - I wonder if anyone actually runs one that big, 32 mainframes would be horrendously expensive - while Linux clusters with hundreds or thousands of nodes are quite common.

Re: COBOL: Thinking about it wrong

#110

Earlier quoted context omitted.

> I learned that COBOL has the most accurate arbitrary precision math, surpassing modern languages. Maybe that was true 20 years ago.

It was not, but for the most part languages don't default to arbitrary precision (i.e., sinple mathematical operators with decimal literals typically gets you binary floating point, not arbitrary precision decimal), even if they have arbitrary precision available at the language or standard library level.

Guess I was wrong. It’s fixed point, and also what you said — COBOL defaults to it. It still makes it easier to write software that need to do a lot of calculations like that.

https://medium.com/the-technical-archaeologist/is-cobol-hold...

Post reply on HN