Skip to content
loading...

Have you ever used COBOL?

mayankjoshi profile image mayank joshi twitter logo github logo ・1 min read

Little curious (11 Part Series)

1) How does dev.to choose which post should be on the top? 2) Is PHP Dying? 3 ... 9 3) Have you ever used COBOL? 4) What is a project, you are really proud of? 5) If you were a recruiter, what would be your recruiting criteria? 6) What are the weird things people ask you, when they comes to know you are a developer? 7) What is your favourite operating system? 8) What is the best Node.js template engine? 9) A feature upgrade for the dev platform πŸ’‘ 10) What rest API authentication method do you prefer? 11) What is the new tech stack you learned during Quarantine?

COBOL once a popular language is now totally diminished.

So, if you have or still work in COBOL, I want to ask following questions:

  1. Have you ever used COBOL, if yes then what is the project you have done?
  2. What is the best thing you like about COBOL?
  3. Does anyone still use COBOL?
  4. What are the most popular software written in COBOL?
twitter logo DISCUSS (24)
Discussion
markdown guide
 

Disclaimer: I have no technical knowledge about COBOL. However, I have heard from co-workers that certain companies are still hiring COBOL developers and are willing to hire you even if you don't know COBOL but is willing to learn. I have also heard that it is confusing AF.

 

That's something exciting to know. I mean company still looking for COBOL developers, and even ready to train them, They must be doing something really serious.

 

Most of the COBOl that exists in production today are in legacy systems that have been operating for decades. Think UPS and other very old companies. I worked for UPS as an intern, and they strongly believe in that if it works, don’t change it. However, I dare to ask the question: what if it breaks? Who is there to fix it then? COBOL developers are getting harder to come by. Why not embrace change and use modern tech with a large talent pool? The answer to that. Idk

Sometimes replacing complex, stable systems with "something new" just for the sake of using the shiny new toys is a very risky proposition. COBOL works just fine, the language has evolved over the years, so why risk a business just to use X instead? Some systems are so complex that redeveloping them would take years and likely lead to failure. A good example is the Government of Canada pay system. The old one had its issues, but it worked. The new one has been a disaster since it was pushed out the door four years ago.

It's not that hard to learn COBOL. Hell, I just had to learn CoffeeScript (Coffee what?) to look into enhancing a third-party component we're using. Not exactly the most in-demand skill.

 
  1. I used to be a COBOL dev working for a big shot in the credit card industry.
  2. The best thing about COBOL would be that its easy to understand and write (if you ignore all the spaghetti code people end up writing).
  3. Actually, a lot more than you think. Our financial infrastructure is still heavily dependent on billions of lines of codes that were written around the 80s and they're is still maintenance and development going on around it.
  4. I don't think COBOL software is that popular, if it is, I didn't hear about it. Mainframes were used by big businesses so COBOL never reached the masses as today's programming language & software does. But COBOL has come a long way, now you can code COBOL on unix systems as well.
 

True. The language has also evolved, even with OOP support (whether that's a good thing is another story). It's not stuck in time in 1970.

I'd consider getting back into it if the offer (work and money) was interesting.

 
 

I took a COBOL course when I was in university, but that was the extent of my COBOL journey. 😎

 
 

Just school assignments but this was more than 20 years ago πŸ˜‰

33 and 27 years ago for me. Yikes. Back in 1987 it was even on MS-DOS using Microsoft COBOL. In 1993 it was on a university mainframe running VM.

 

I worked in Cobol in 82 for a few month.
It requires tons of writing,
One thing I liked about it, and never found in another language.
If you had two different records (structs) where some of the fields had the same names, there was a command "move corresponding" which copied all fields that had the same name !

 

I have used Cobol for many years in development and teaching.
Cobol has a very rigid structure (called division), where it is necessary to specify, name, input-output, type of file, its organization and its access form. Remember that Cobol worked a long time as a storage medium for the tapes.
There is another division where the fields are described, etc.
Then would come the division of the code.
I worked in a bus company with an ncr mainframe, I don't remember the model and also with ibm 360.
To teach classes I used rm-cobol85 in DOS and in CP / M I used cobol-80. I know Visual Cobol exists, but never use it. All this already 30 years ago. And as they comment in other posts if there is Cobol code running, mostly in banks. Popular software I do not know since the company had its own development team. think that energy should not be spent on developing in Cobol, only that you hire a company that needs it and have a good salary.

 

I've written only three programs in COBOL, one of which was somewhat useful. The other two were games. The year was 1990, I was on a data entry temp assignment at a company that repairs industrial equipment. I wrote a short COBOL program (with embedded Oracle SQL) to make a list of outstanding work orders, grouped by customer service representative and separated by form feeds. The customer service reps loved it and IT hated it, because I hacked my way out of a captive VMS account to access COBOL. The games I wrote were equally trivial, the very trivial "worms" game, and a strategy-naive (but correct by the rules) implementation of Othello. This was VAX COBOL, so there were sentence syntaxes available for telling the cursor where to go.

The best thing I like about COBOL is that (in the PROCEDURE DIVISION, anyway) program syntax is constructed almost entirely out of English words. I posted on Halfbakery that I think this might make for a more usable language if one happened to want to code, but not have access to a hard keyboard, say having to code on a mobile device's touchscreen, which is infuriating enough for normal text, but COBOL uses punctuation more sparingly than normal English. I'm thinking if you fine tuned the predictive spelling to bias itself toward COBOL reserved words, one could write COBOL code with some fluidity. The batch-oriented nature of traditional COBOL does not suit it to mobile app development, which has to be very event-driven and asynchronous, but take the idea of a syntax rich in words and not so rich in punctuation symbols, and rewrite the logic to something more event-driven, and I think you might have something useful.

As lurch commented on my Halfbakery post:

...I will support anything that allows the phone to be programmed on-the-phone. It's really a computer, and what is a non-programmable computer?

 

I know 2 people that working as Cobol developer. This language used mainly in mainframe servers.
They working in banking industry .

 

Still they are working it.😳 I thought even legacy software would have migrated.

 

They working in banking industry. This industry don't migrate so quickly.

COBOL's killer feature is what they call an "audit trail". I haven't familiarized myself with that feature, but I've heard that it's rock solid, enough to inspire confidence even in bankers and accountants and the like.

 
 
Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

mayank joshi profile image
I love system design and most of the time I find myself learning or designing one of them.