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

91–100 of 116 posts

Re: COBOL: Thinking about it wrong

#91

Post by skissane »

COBOL (or at least some of its dialects) has some really weird features I’ve never seen anywhere else. For example, only just the other day I learned that IBM mainframe COBOL has a “REVERSED” clause on its OPEN statement, which opens an input file for reading backwards. Apparently it only works for fixed length record format files, and only for files stored on tape. It relies on the fact that the (non-SCSI) IBM mainframe tape command set has a “READ BACKWARDS” command which reads blocks off a tape in reverse order, by playing it backwards.

Back in the day, memory was very small, and hard disks were unavailable or very limited in capacity, so many COBOL programs used tapes as input, output, and temporary storage. OPEN INPUT REVERSED meant you could write out a temporary file to a tape, close it, and then immediately re-open it to start reading it back in (albeit backwards), without having to wait for the tape to rewind in between. It was particularly used to speed up external sorting algorithms (although those were more commonly done in assembler than COBOL, to maximise efficiency)

Re: COBOL: Thinking about it wrong

#92

Post by SamuelAdams »

JohnFen wrote: post #25
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…

> the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV That's pretty much the last thing that I'd worry about. A company that evaluates potential hires that way is not a company that's worth working for, in my opinion. And most companies I've encountered wouldn't think that way.

You would be surprised. Don’t get me wrong I would love for companies to not show prejudice based on a candidate’s current tech stack.

However once you are outside of the SV bubble you will notice a lot of companies dismiss candidates based on their tech stack. The only time I’ve ever seen an inexperienced tech stack hire is from personal referrals from someone already working at said company.

Re: COBOL: Thinking about it wrong

#93

Post by skissane »

sillybov3456 wrote: post #64
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…

This is all based on a myth though, primarily the myth that "only COBOL" developers are a common thing (people believe this for COBOL even though it's never really been a thing for other languages, wasn't even ever really a thing on mainframes, increasingly they are majority Java). What I'm getting at is that you aren't going to find a ton of jobs where you are working on COBOL but somehow avoiding Java when the two…

> This is all based on a myth though, primarily the myth that "only COBOL" developers are a common thing

Anyone who knows anything about COBOL knows that there’s rarely such a thing as “only COBOL”. The majority of the remaining COBOL shops are IBM mainframe, which means it isn’t just COBOL-CICS, JCL, VSAM, IMS, DB2, TSO, ISPF are all in the mix as well (maybe not all of them at the one site). And if you aren’t doing it on an IBM mainframe, it is probably deeply integrated into some other platform - e.g. PeopleSoft still uses COBOL for some of its batch jobs (especially payroll), and while I’ve never looked at its COBOL code, I’m sure it isn’t vanilla COBOL either, it has some PeopleSoft specific calls in it. Or maybe you are doing Oracle Pro*COBOL (SQL precompiler for the Oracle RDBMS). It’s really no different than Java - who does “just Java”, as opposed to J2EE or Spring or whatever?

Re: COBOL: Thinking about it wrong

#95

Post by lokedhs »

msla wrote: post #41
RobotToaster wrote: post #11

Earlier quoted context omitted.

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

GnuCOBOL not only runs on Linux, it's pretty far along https://gnucobol.sourceforge.io/faq/index.html > GnuCOBOL implements a substantial part of the COBOL 85, COBOL 2002, COBOL 2014 and upcoming COBOL 202x standards, as well as many extensions from existing COBOL compilers. It's also in the Ubuntu package repos, from a quick check. The GCC Cobol aspirant recently gained compliance with Cobol-85 https://lwn.net/Artic…

Unless things have changed lately, it's still very annoying to get your Gnu COBOL program interacting with the test of your system. Something as simple as reading a file is a lot harder than you'd expect. And opening a TCP connection requires you to use specialised API calls to call the C functions directly, and the syntax for that was pretty horrible.

COBOL is designed for handling well formed input data, process them, and then return well formed output to the next step in the chain (on the mainframes this is coordinated by JCL but I'm not sure how you do it on Linux).

Re: COBOL: Thinking about it wrong

#96

Post by citrin_ru »

msla wrote: post #46
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…

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.

I don’t know if it is official IBM strategy but from outside it looks like they want all their old technologies including z/OS to die so IBM can focus on software consulting without need to build/maintain anything big themselves.

Re: COBOL: Thinking about it wrong

#97

Post by skissane »

msla wrote: post #46
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…

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 unlikely IBM will sue them.

The easiest way to get z/OS install media is to sign up for zPDT – it costs many thousands, but still a lot cheaper than what IBM charges for z/OS for an actual physical mainframe – and then you get the the ADCD media with that. The problem is, starting with z/OS 1.15, IBM began encrypting the ADCD media. As part of the installation, the media is decrypted, using the key on the hardware dongle – but the decrypted copy is watermarked with the dongle ID, meaning that IBM can trace back any leak to the individual customer responsible for it. This means people are no longer willing to publicly share ADCD media, although I've heard rumours of some people passing it around privately, only to trusted individuals. Someone could reverse-engineer the watermarking and remove it, but I'm not aware anybody has done that–I think people would still worry, what if they failed to completely understand the watermarking, and hence some of it survived?

Re: COBOL: Thinking about it wrong

#98

Post by taraharris »

But I don't think about COBOL at all, and neither should you. The problems that legacy banks, airlines and government institutions have are not my problems.

The management class doesn't want to hear this. Their only goal is to lower maintenance costs on their legacy systems by bringing in new people to ensure lower wages, so they fund all this nonsense about this very dead language.

"What is it with these nerds that don't want to write COBOL code? It's all just coding, isn't it?"

You know they're desperate when they resort to astroturfing.

Re: COBOL: Thinking about it wrong

#99

Post by geysersam »

SoftTalker wrote: post #67
poulsbohemian wrote: post #62

Earlier quoted context omitted.

>What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know. This could be what you mean, but isn't the problem here one of access? I know just enough about JCL, CICS, etc to be dangerous, and never found any of the mainfra…

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?

Re: COBOL: Thinking about it wrong

#100

Post by cratermoon »

AndrewDucker wrote: post #12
cratermoon wrote: post #8

Earlier quoted context omitted.

COBOL is good for dealing with money because it was built with the sort of numeric types required as a natural part of the language. Popular programming languages treat them as an afterthought and provide awkward library functions, if they have anything at all.

C# has Decimal built in. Enough precision for any money-related calculation.

Which of the top 10 languages from the Tiobe index have a decimal type baked* into the language?

* Is a type in the standard library "baked in"? I lean towards no, but I'll give the language A for effort anyway.

Post reply on HN