COBOL: Thinking about it wrong

https://gcn.com/cloud-infrastructure/2023/01/cobol-youre-thinking-about-it-wrong/381563/

by rbanffy • 3 years ago

69 112 3 years ago

gcn.com

nyerp• 3 years ago

Popup ad with 15 second delay was too annoying. Didn't read the article.

smarks• 3 years ago

Click on the link to skip the delay.

ElfinTrousers• 3 years ago

Even after a 44% bump, the salaries for COBOL positions aren't impressive compared to other specialties. And that's before the quality-of-life question.

ptero• 3 years ago

The quality of life may not be bad at all. I have a relative who maintains old code for a public utility (I think most of it is PL/1). While the salary is not FAANG-like it is OK and the job security and the sane 9-5 schedule with the opportunity to work remotely are pretty big benefits for someone on the wrong side of 60. My 2c.

kjs32• 3 years ago

Yeah...I know quite a few Cobol programmers. They make good, not extravagant, money. But they also have low job stress, no 'crunch mode'. Production changes are very carefully considered and controlled because of the consequences of botching one. No 'move fast and break things'. They're home with the family at a reasonable time every day. So it's a tradeoff, and a good one for many people.

MelvinButtsESQ• 3 years ago

COBOL is easy. JCL is the hard part.

cratermoon2• 3 years ago

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.

AndrewDucker2• 3 years ago

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

JohnFen8• 3 years ago

shiver

That's a fact. A couple of years ago, I had to brush off my JCL skills for a job. It reminded me of why I was so happy when I didn't have to use JCL anymore.

YeGoblynQueenne5• 3 years ago

On the bright side, you can generate all your JCL with Rexx.

bitfhacker• 3 years ago

Or with chatGPT!!

LangIsAllWeNeed• 3 years ago

Ya Cobol is the future!

W-Stool• 3 years ago

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.

chocolatelab82• 3 years ago

One of the slides by some IBM consultants presenting at the financial firm I used to work stated "Western Civilization runs on the mainframe." Considering how much banks still use mainframes, this is probably true.

LeonenTheDK• 3 years ago

I recently listened to a podcast episode which featured a gentleman who teaches mainframe related things at a university in the US and is deeply involved with the Open Mainframe Project. His statistic was 95% of financial transactions touch a mainframe somewhere along the way.

From what I know, considering it's not "just" banks but pretty much any long running financial business (IE insurance companies), I believe it's one of the most used but least talked about technologies out there.

3pt141592• 3 years ago

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 the software languages we use really do matter. If all Ruby interpreters disappeared overnight it would cause global havoc. Real panic. Trillions of dollars of damage.

But because we've learned to rely on these languages continued existence we can undervalue any one of them, including COBOL. I don't because I've thought about it and concluded that we're essentially building on things akin to writing or mathematics. Our building blocks are vital, even if they're easy to take for granted.

kjs32• 3 years ago

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.

sillybov34562• 3 years ago

Its peak hacker news to come up with a term like "legacy industry".

santoshalper2• 3 years ago

I suspect they mean "systems that use a lot of legacy technology" rather than "banking and insurance are legacy business models", but it is HN, so who knows. Either way, pretty amusing.

moomin5• 3 years ago

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.

bitwize• 3 years ago

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 civilization. Not having muh NPM is a feature, not a bug.

You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.

Dude. COBOL has entire modern IDEs written for it.

VulgarExigency• 3 years ago

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.

YeGoblynQueenne5• 3 years ago

> If you need Linux, create a Linux LPAR on your mainframe.

Or use the super secret hidden unix mode.

(and get stuck in an ed prompt. Fun times ?).

msla3• 3 years ago

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.

anadem• 3 years ago

COBOL has entire modern IDEs written for it.

In fact the very first visual compile/debug environment was written in COBOL over 40 years ago: Micro Focus's Animator (from which Microsoft paid to use the patents in their Visual products iirc).

moomin5• 3 years ago

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.

RobotToaster• 3 years ago

I assume GnuCOBOL can run on GNU/Linux.

https://gnucobol.sourceforge.io/

msla3• 3 years ago

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/Articles/922951/

There is active Free Software development on Cobol tools.

moomin5• 3 years ago

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.

II2II• 3 years ago

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 specific as to how it is used (which is important since COBOL seems to be a domain specific language) and relying upon authority when claiming it is modern.

moomin5• 3 years ago

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.

benjaminpv• 3 years ago

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 heat around COBOL dying down and facing that once again with the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV during my next round of interviews didn't seem at all appealing.

That mentality should set the expectation for anyone looking into a COBOL job. It's not just this job, it's the next one.

haskellandchill• 3 years ago

You don't really want to work with those people anyway. Some hiring managers will see it as a cool thing. As long as you do a project in whatever you want to target next to stay fresh you shouldn't have any problems except from those who hire superficially.

JohnFen8• 3 years ago

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.

SamuelAdams• 3 years ago

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.

7thaccount2• 3 years ago

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.

guestbest• 3 years ago

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.

avgDev• 3 years ago

If you know COBOL and know other languages and are fluent in "current" tech, then I see nothing wrong with consulting for $300 an hour doing some COBOL.

Company I work for still uses AS400, which has been released in 1988 just after I was born. We have a dev who supports it. This isn't a small company either.

COSTCO is still using and a lot of huge organizations.

I'm focused on newer tech C#, .NET, Blazor but I do interact with DB2 database which is the backbone of that old system.

At one of my interviews somewhere I mentioned that a lot of apps I'm writing are just extending AS400 and the dude interviewing me was really hyped up. He has spent a lot of time with the green screen in his younger years. The job had nothing to do with AS400, but that conversation got me an easy offer.

bluGill• 3 years ago

Most consultants cannot get $300/hour for COBOL though. It is those who have specific other knowledge - like experience in the system before they retired who can get that much.

sillybov34562• 3 years ago

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 are connected at the hip on the platforms they are used on.

skissane4• 3 years ago

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?

mattnewton• 3 years ago

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?

yobbo2• 3 years ago

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

NeutralForest• 3 years ago

It's a mix of both, I know that some companies do make a good living writing transpilers to languages like Java or C#. But it also require lots of business knowledge to keep track of the changes so you're definitely right in that aspect.

JohnFen8• 3 years ago

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.

sidpatil• 3 years ago

The US DoD recently migrated some of their COBOL systems to AWS GovCloud. One of the steps was automated translation of COBOL to Java.

https://tsri.com/news-blog/u-s-department-of-defense-mainfra...

cutler• 3 years ago

So it's true - Java is the new COBOL.

GartzenDeHaes• 3 years ago

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.

skylanh• 3 years ago

It would be if you could be bought by IBM...

scarygliders• 3 years ago

As someone who learned COBOL in British college in the late 1980's, I can confirm that the language was/is quite readable and accessible. I still have the COBOL textbook from back then; Andrew Parkin, COBOL For Students, second edition, ISBN 0-7131-3477-1

I distinctly remember at the time really enjoying learning to code in it - it spoke to my logical-thinking (but quite young) brain a lot.

However, after college, for whatever reason I didn't use that COBOL knowledge at all. If only I knew then what I know today - that COBOL is still somewhat in demand and that if only I kept in with it over the years, I could quite probably have made quite a good living from it.

Young me was quite naive and silly ;)

yobbo2• 3 years ago

with 800 billion lines running in production systems daily

Unrealistic. This would be equivalent to 100.000 linux kernels.

Hardwired8976• 3 years ago

not really, cobol is really verbose and there is heavy use of macros

hiAndrewQuinn• 3 years ago

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.

greenyoda• 3 years ago

There's lots of software for emulating IBM 3270 terminals over TCP/IP using the tn3270 protocol.

https://en.wikipedia.org/wiki/IBM_3270#Telnet_3270

BlandDuck• 3 years ago

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?

JohnFen8• 3 years ago

You're not thinking wrong. COBOL is, compared to modern languages, very straightforward. It's also very different, though, and so it can feel alien to programmers who only know the new stuff.

rbanffy2• 3 years ago

No direct experience with either, but, from what I understand, a COBOL application written to run in CICS looks a lot like a serverless app, with the difference that the company owns the multi-million dollar server.

altacc• 3 years ago

You raise a good point. I can read COBOL to get an idea of what it is doing and how it is structured takes a little getting used to, but so do most languages.

However, in my company (insurance) we have 3 COBOL systems (thanks to mergers) and one is on a rapid track for decommissioning not because it is COBOL, but because it is COBOL written in an obscure framework that was never popular and also coded in a non-English language, requiring knowledge of that language to understand the business logic. We can outsource some mainframe maintenance but not that one. The other mainframes will be around for at least the next 10/15 years.

SoftTalker3• 3 years ago

COBOL the language is pretty simple, you’re right. I learned it in a few weeks in my first job out of college in the early 1990s.

Even today, you can grab Gnu COBOL and learn the language.

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.

poulsbohemian2• 3 years ago

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 mainframe systems to be that difficult to learn (it's all basically batching, queueing, scheduling...) but without access to a mainframe, it's kind of a non-starter to actually get hands-on with any of this stuff. IE: thanks to the multi-decade shift to open source, we've got generations that have that skill set because it was accessible.

ipaddr• 3 years ago

Your experiences aren't as straightforward as moving from perl to php but sure anyone can pick it up but it is a journey. I remember finally getting jcl language clicking for me and feeling like I accomplished something.

markphip• 3 years ago

Some other good points have been raised about what makes it complex, I will add another.

I never learned Cobol, but I learned programming in the 90's on the AS/400 where Cobol and RPG were the primary 2 languages. I obviously used RPG. They are both easy to learn and powerful for what they were meant for but they are also commonly used to create massively monolithic programs where massive transaction programs are all written in a single file or with a lot of "copybooks". It makes it a lot harder to reason in your head what is going on as well as the side effects. Things like unit tests are just non-existent so it is just difficult to make changes because of the potential consequences. Especially when these monoliths are handling such important data.

We wrote our RPG in a very API driven fashion where we avoided monoliths. I think you pay a small performance penalty for this but it always made our code easier to maintain.

Of course it also takes a very long time to compile these programs so the Edit/Compile/Debug cycle is not fun or productive.

agumonkey• 3 years ago

data definition syntax is quite strange at first but conceptually there's nothing special

and yeah legacy code of really sauron like

zerd• 3 years ago

I only have minor experience with COBOL, but in my mind the issue is that those 800 million lines of code don't have a single unit test, because testing COBOL is really hard. Which makes it dangerous to do any refactoring.

Specifically the snippets I've seen do some in-line SQL to get its data, some business logic and then updates. The logic is rarely in a procedure that takes parameters, because that doubles the number of lines of code you need. So the only way to test it is to bring up a database, insert some test data, assert and clean up the database again. Which is a lot harder since "insert some test data" gets complicated because of different constraints and triggers etc. Then running it regularly is harder than it should, there's no SQLite equivalent database so you typically need to run it on a mainframe etc.

I've worked on replacing a piece of functionality from COBOL to Java, and I was working from the business requirements that was basically a large spreadsheet of conditions and results. E.g. if age > 67 and not retired but have more than 3 kids, etc then this value. The code I wrote was gnarly because of all the combinations of different conditions, nested ifs 3-4 layers etc. And then there was ambiguity if multiple conditions hit, which one took precedence. I asked if I could look at the equivalent COBOL and the actual logic was about 10 lines long (not including headers, comments etc). Wish I had seen that before I started coding. It was quite readable and well commented too. So the actual language isn't _bad_, but the lack of tooling around it is severely lacking.

nickpeterson• 3 years ago

I know hindsight is 20/20, but that feels like the perfect setup for a rules engine like Drools.

edw519• 3 years ago

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?

No.

800 billion lines of COBOL = 1 million lines of BASIC

A gross exaggeration, of course, but after 7 years of COBOL, I discovered BASIC and instantly became 10X of my former self.

I would never go back. I get enough overhead from my bosses. I don't need it from the tech too.

heisenbit• 3 years ago

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.

aeschinder• 3 years ago

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.

SoftAnnaLee• 3 years ago

I keep hearing about COBOL and how there is demand for it. But I'm wondering if there are any avenues to learning how to write COBOL and get experience writing the kind of code that these industries require?

jimt1234• 3 years ago

My mother built her career on COBOL from the mid-70s to the late-90s. She's retired now, but still talks about what a great language it is. She tried learning Java in the late-90s, toward the end of her career, but hated it. "What's an object? Everything? Everything is an object? That's just dumb." LOL

And yeah, she still gets offers for consulting work, but she wants no part of it. She's done working.

drewcoo• 3 years ago

COBOL (COmmon Business-Oriented Language) was designed by Grace Hopper to make it easier for business folks to write code.

https://www.zdnet.com/article/cobol-grace-hoppers-gift-to-th...

That goal a flop, so programmers had to take over.

Wasn't there a Cucumber/Gherkin story here really recently? That grew out of Fit/Fitnesse (from Ward Cunningham of "tech debt" and "the wiki" fame), which was intended to have business folks write test cases to define how the delivered software would work. And as many people in the Cuke threads pointed out, Cuke fails, too. (As did Fitnesse.)

https://en.wikipedia.org/wiki/FitNesse

Bottom line: There is a ridiculous impedance mismatch between the business side of the house and engineering. Engineering attempts to create a programming language for MBAs is not a solution, but an expression of that mismatch.

kps• 3 years ago

COBOL was designed by Grace Hopper to make it easier for business folks to write code.

Not quite; it (FLOW-MATIC, rather) was designed so that senior management could feel that they could read their organization's code.

I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.

tragomaskhalos• 3 years ago

There is always money to be made by peddling the idea that you can bypass those pesky programmers and get Don from accounts to write his own applications instead. See also: most low-code / visual programming environments.

jmclnx• 3 years ago

That last application garnered plenty of attention during the pandemic when state UI systems running COBOL were unable to handle the unprecedented flood of new applicants

COBOL was not the issue, it was all the "webizied" front end developed for people to use via a browser that had the issues. A couple of articles came out with details that, as usual, the mainstream press ignored.

1bent• 3 years ago

My mom learned COBOL while she was getting a degree in accounting; according to her, the language is such a clear mapping from narrative jargon usage in accounting and bookkeeping that she was using features her class hadn't covered, in test solutions, without realizing it, until her teacher asked if she was studying outside materials.

My conclusion was, if ever I want to do business data (transaction) processing, I'll learn it.

I also programmed a mainframe, with JCL on punch cards, in assembler and PL/1, in college; I'm glad I did; without that experience it might be hard to appreciate how radical and revolutionary unix was.

hosh2• 3 years ago

I grew up hearing COBOL as a joke language, until one day, I learned that COBOL has the most accurate arbitrary precision math, surpassing modern languages. This is crucial for financial applications. When I then think about how it doesn’t seem any more verbose than SQL, COBOL seems to me like a very respectable language.

Somewhere early in my career, I worked with an accounting app that thought a double float is good enough for a ledger. It was not. We spent too much time trying to track down discrepancies when closing the book for the year, only to find out that a double float is not precise enough for bookkeeping. Lesson learned.

valenterry2• 3 years ago

I learned that COBOL has the most accurate arbitrary precision math, surpassing modern languages.

Maybe that was true 20 years ago.

dragonwriter• 3 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.

docandrew• 3 years ago

Ada’s support for fixed-point arithmetic is worth looking at too for financial apps.

santoshalper2• 3 years ago

This article is extremely disingenous.

* Can you build "modern" style software in COBOL? - Sort of yes.

* Should you build a new system today using COBOL? - Absolutely not.

* Is ANY of the COBOL code you run into in the wild going to be architected in a recognizable way to modern sofware engineers? - lol no.

xiaodai• 3 years ago

I would do cobol if it's 2000 a day

skissane4• 3 years ago

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)

jasomill• 3 years ago

IBM 3590 and 3592 SCSI drives support the "READ REVERSE" SCSI command[1] which (in variable-block transfer mode) is equivalent to the "READ BACKWARD" channel command.

For application details, see Knuth volume 3 [2], which even has a fold-out chart illustrating tape (and tape operator) movements involved in various sorting algorithms[3].

In brief, reading backwards allows you to use tape as a stack.

[1] https://www.ibm.com/support/pages/system/files/inline-files/...

[2] https://archive.org/details/B-001-001-250/page/299/mode/1up

[3] https://archive.org/details/B-001-001-250/page/n356/mode/1up

taraharris• 3 years ago

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.

COBOL: Thinking about it wrong

Related Stories