Do You Know Cobol? If So, There Might Be a Job for You. (wsj.com) 335
Despite its advanced age, Cobol is still the most prevalent programming language in the financial-services industry world-wide. Software programmed in Cobol powers millions of banking transactions every day and underpins critical computer mainframes. WSJ: And Cobol isn't going away anytime soon. Banks and other companies have come to the uncomfortable realization that ripping out old mainframes is pricey and complicated. Transitioning to new systems is likely to take years, and besides, a lot of the older tech works just fine. The problem is that Cobol isn't popular with new programmers. So, with a generation of Cobol specialists retiring, there is a continuing hunt to find a new generation of programmers to service this technology. In Texas, Mr. Hinshaw's (an anecdote in the story) company, the Cobol Cowboys, a group of mostly older programmers, is training U.S. military veterans in the programming language. Accenture is coaching hundreds of Cobol programmers every year in India and the Philippines to work at banks. In Malaysia, one consultancy that provides engineers versed in Cobol for its clients, iTAc MSC Outsourcing, has adopted the slogan "Keeping the Dinosaurs Alive." A host of companies offer online courses in Cobol in places like South Africa, India and Bangladesh. Developing economies are key technology-outsourcing centers for banks. Further reading: Major Banks and Parts of Federal Gov't Still Rely On COBOL, Now Scrambling To Find IT 'Cowboys' To Keep Things Afloat.
Seriously? (Score:5, Insightful)
Sure I'll go ahead and learn what I need to to keep your stack afloat.
What's that? You don't want to pay me a reasonable wage? Well then! I guess we have a problem indeed. Scramble on, fine HR folks at "Major Banks and Parts of Federal Gov't"!
Re:Seriously? (Score:5, Insightful)
Exactly this.
COBOL isn't hard. Whatever, it's a language.
But if you want to take smart people away from their shiny modern languages and dev stacks, and ask them to put up with bureaucracy, then you need to pay them at least commensurate salaries to what they'd get elsewhere (if not MORE).
These are really stories about banks not wanting to pay talented devs to put up with their BS.
Re:Seriously? (Score:4, Interesting)
The hard part is reading and following piles of legacy code, some of which may have been written in the "go to" days.
Re: (Score:2)
Been there! I remember one mass of code that I called "spaghetti code with meatballs". For years it was unchanged because nobody but the original guy wanted to work on it. When he left they asked me to rewrite the SOB from scratch. Naturally, there wasn't any documentation.
Re:Seriously? (Score:5, Informative)
No even that is not 'hard' tedious often but not hard. People thought it was going to be hard, until they actually tried around y2k and it turned out to be not hard just a lot of work.
The hard part if there is a hard part is supporting the stack around it. What people, especially people on Slashdot who wrote some Microfocus COBOL in Windows for a college course some time, about COBOL is it does not run in vacuum. Its not the COBOL program that is hard. Its the fact that COPYBOOK is referenced in 65 different programs. Its the 500 JCL job steps before and after with their sync sorts and COND statements. Its the FTP and character conversion steps; and stuff that is scarping CICS and CICS web interfaces around the COBOL you need to worry over.
All this stuff amounts to Rube Goldburg devices that happened to be constructed from very very reliable and consistently operating components. So it all works and humms along for decades but try and replace any part of it with something new and feel the pain of running a square peg into a round hole.
Re: (Score:3)
But if you want to take smart people away from their shiny modern languages and dev stacks, and ask them to put up with bureaucracy, then you need to pay them at least commensurate salaries to what they'd get elsewhere (if not MORE).
These are really stories about banks not wanting to pay talented devs to put up with their BS.
No, they're not going to pay well. Why do think they're doing this (from TFS):
Accenture is coaching hundreds of Cobol programmers every year in India and the Philippines to work at banks.
Can't wait for all the banking systems to melt down a few years later
Re: (Score:2)
No, they're not going to pay well. Why do think they're doing this (from TFS):
It is the teachers who are getting paid well. If you are ever lucky enough to have accumulated knowledge about something that the noobs aren't doing, there will come a time when you can cash in on it. I know I have. All it takes is knowledge of both old and new.
4. Profit!
Re: (Score:2)
This. Years ago I was a COBOL coder for a major financial company. The anachronistic culture - having to over-dress for office work, micro-managed email and personal phone call quotas - drove me out. Turned out to have been the best unintended career move ever.
Re: (Score:3)
Re:Seriously? (Score:5, Interesting)
I programmed in COBOL. I liked it.
It was easy for me to understand.
What was damned near impossible was straightening out the spaghetti code already in place.
The way to understand an existing system is to fuck around with it and get inside the programmer's head.
Once done, I can anticipate what's coming.
When a system is a hybrid of decades of code by quacks and pros alike, it's a goddam maze.
Management doesn't take that as an excuse and I excused myself from the management.
While the wage was competitive, the stress wasn't worth it.
I'll do startup with COBOL, but there's no market for that.
Re: (Score:2)
They may also need to let go of things like expecting people to tie onions to their belt and rags around their neck.
Re: (Score:2)
But if you want to take smart people away from their shiny modern languages and dev stacks, and ask them to put up with bureaucracy, then you need to pay them at least commensurate salaries to what they'd get elsewhere (if not MORE).
These are really stories about banks not wanting to pay talented devs to put up with their BS.
Where do they say that they are attempting to underpay these folks?
I've been doing something similar recently, and the pay is tremendous.
Re: Seriously? (Score:3, Informative)
cobol may not be hard, but the IBM mainframe environment/ecosystem those cobol apps run in is not trivial.
Re: (Score:3)
Yeah, but every sufficiently large organization, corporation, and government has things about it that are untenable. For example, I'm working on a scala microservices stack right now, and it's relatively new. But the developers that deployed the original iteration didn't really know the language or the platforms they're working on, so the project six months in is as bad or worse than the worst vb and java apps I've ever seen.
Fucking verbose case classes EVERYWHERE, and entire sections of architecture that s
Re: (Score:3)
You're demanding that salary only 15 years out of college? Wow, just... wow. That's well above the norm even in Silicon Valley.
That's his point. If you want someone to learn a language that is old-fashion, tedious, has limited growth potential, and is full of bureaucracy then you need to pay above market rates. At most programming jobs you are paid marketing rates and continue to stay up to date with technology and therefore can get a new job when your current job ends. Many programmers are even willing to take below market rate jobs if the work is interesting and has learning potential. Taking a job as a COBOL programmer, you
Re: (Score:3)
There is nothing to maintain. Skills don't just rot away.
Yes they do. Ask any foreign language speaker. They have to constantly maintain their language or they start to forget it. I used to be an excellent at C++. I haven't used it in 10 years and my skills are definitely a lot more rusty. I've forgotten many of the shortcuts for debugging, etc... I've also forgotten most of the calculus and physics I've learned in college as well as no longer have the periodical table memorized. I once read that you need to read X (don't remember the number) books per yea
Re: (Score:2, Interesting)
It's nonsense anyway, the idea that Cobol is the most prevalent language in financial services still is complete and utter drivel.
I've worked for a number of financial services organisations, including banks, and I've not come across any still using it. After the whole Y2K drama and the amount they had to spend on contractors they spent the following decade deprecating it, and it's nowhere to be seen in the vast majority of financial services organisations anymore.
If you really want to know what the "most p
Re: (Score:2)
Considering many of these jobs are in places where programmers don't get paid much, or there's not much of a demand for them, it looks like Cobol programmers do get paid quite a bit more.
I did a quick search on Glassdoor, in some very non-tech places... Programmers in Jefferson City, MO make $45-65K.. Cobol programmers make $88K. That's probably very good for Jefferson City cost of living.
Re: (Score:3)
I skipped COBOL class deliberately (Score:3)
In my defense, back then, COBOL did not even have an ELSE statement.
It was just pretty dumb.
And all the stuff written in it was stultifyingly boring.
That was the best 1% mark I ever sacrificed.
Re: (Score:2)
It was just pretty dumb.
And all the stuff written in it was stultifyingly boring.
Yes, all about money and stuff like that. Paralyzingly boring. Who cares about lousy old money?
The world makes money go around (Score:2)
But "seriously", if you can code up a new altcoin in COBOL, I will be seriously impressed and not bored, admiring the sheer surrealist abstract impressionist audacity of it.
Re: (Score:3)
It was just pretty dumb. And all the stuff written in it was stultifyingly boring.
Yes, all about money and stuff like that. Paralyzingly boring. Who cares about lousy old money?
Quiet! all these young guys need to think that there's no money in supporting legacy systems.
Stay away! You'll be paid less than minimum wage! COBOL is dead anyhow - this is just fake News!
Re: (Score:2)
> Yeah, who wants steady employment anyway! Stick with Obj-C and Rust and Lisp and the flavor of the month instead...
Never had a problem really.
As an added bonus of sound planning and not being located in Silicon Valley, I can work as much or as little as I like. I can take early retirement any time I want.
Maybe not a good career move in the U.S. (Score:5, Insightful)
So, if you are in the U.S. and you know Cobol already, you might get a few years of employment out of it. However, such jobs will go overseas, too.
Re: (Score:2)
Excellent! More bugs to fix, bugs created by programmers who didn't know what they were doing and were never expected to maintain the codebase in the future and so they made a big unreadable mess that just barely works, usually.
Re: (Score:2)
It's not impossible to make spaghetti with the language, but it's also not that hard to read and follow the logic to make block diagrams, flowcharts, etc from old code.. This is just a guess but I'd bet there are tools out there to do just that.
Re: (Score:3)
I'm around 10 years from retiirement and would happily ride that wave into the sunset. My very first real job was coding COBOL on a Wang VS80 (later we upgraded to the VS100, woo), I'm sure it would all come back to me.
Re: (Score:2)
'In the U.S.'
So what are other countries using? Because a few more years of 'do what we say or else' and banking, being the reserve currency and the seat of the world's energy markets will just go overseas. Find out what they use and learn that.
You can learn Cobol well enough to get a job (Score:3)
It's the context of the job that matters (Score:5, Insightful)
Simply knowing COBOL isn't the deciding factor. Could I stomach being employed in the banking industry and facilitating the awful shit they pull? No. So whether I know COBOL or not is irrelevant.
Re: (Score:2)
I've worked at/for a lot co's, and jerkativity is NOT limited to just banking.
Re: (Score:2)
Simply knowing COBOL isn't the deciding factor. Could I stomach being employed in the banking industry and facilitating the awful shit they pull? No. So whether I know COBOL or not is irrelevant.
I'm curious.. What stuff do they pull that you don't like?
Re: (Score:2)
If you are actually seeking knowledge and not just trolling to start a confrontation from the expected answer, I am not the person to educate you about the banking industry. That history is well documented. Go read, since you've managed to grow to adulthood without paying attention.
Actually, instead of assuming something, I was asking to be sure what issues where being alluded to. I may not interpret history the same way as you, so it was an effort to stay focused and relevant in the discussion.
My perspective on the banking industry is similar to my perspective on oil refineries. They have their bad points and can be messy, but we'd be in bad shape as a society without them.
However, reading between the lines of your two posts, I'm guessing you are just wanting to bash the banking
Re: (Score:2)
Simply knowing COBOL isn't the deciding factor. Could I stomach being employed in the banking industry and facilitating the awful shit they pull?
Now you know why out-sourcing to countries with workers more interested in gainful employment than nursing old grievances makes good sense.
Do You Know Cobol? If So, There Might Be a Job for (Score:3)
do you know cobol? IF so, there MIGHT be a job for you.
Yeah, sure let me get right on that. If, might; why not waste my time on vague promises?
Re:Do You Know Cobol? If So, There Might Be a Job (Score:5, Funny)
I'll learn a language that has an IF MIGHT loop, looks awesome!
Re: (Score:3)
Trump would love COBOL; it's usually in all capitals and makes small things sound important, as if you are God commanding an army of millions who don't question orders.
Would you even be looking for a job? (Score:4, Insightful)
The way COBOL programs are structured I think you had to have been programming in the 1970's to really understand the idioms and work flow. That means you may have been on the job for 40+ years already, putting you pretty close to retirement age if you were one of the younger folks to pick up COBOL in the late 1970's.
We're going to hit a brick wall in about 5 years on this, and some businesses will have to learn an expensive lesson about the sunk cost fallacy.
Re: Would you even be looking for a job? (Score:3)
Don't worry. India will do the needful.
Re: (Score:2)
Indian jobs are getting outsourced to Poland, Romania, Brazil, China, Philippines, and Michigan.
Re: Would you even be looking for a job? (Score:5, Funny)
For the love of god and all that is holy - is there any 3rd-world country they *won't* exploit?
Re: India will do it (Score:2)
Re: (Score:2)
And how much would you like to bet on that 5 year prediction? Before you decide, let me give you a little history lesson. I have been in the financial sector since the very early 90's, and every 5 years or so, all of the really smart people claim just what you are claiming, and guess what happens.....
Re: (Score:2)
One of these 5 year periods I'll get it right.
But more seriously if you look at the ages, say some was 20 when they started programming COBOL in 1978. They'd be 60 now. In 5 years They'd be 65. Maybe they'd retire and spend time with your grandkids, maybe you'd work until they're 70 or even 75. What I don't find reasonable is the sustainability of an industry based on a population of 80 year old programmers.
Now here's where my argument falls apart. It assumes people aren't learning COBOL. If you look at dat
Re: (Score:3)
Maybe they'd retire and spend time with your grandkids
oops, that turned unexpectedly creepy. substitute the appropriate pronounce.
Re: (Score:2)
I'm not just how familiar you are with the core banking packages that banks use, but they are quite complex and consists of my components. The only parts that are typically still in COBOL is the part that holds balances and transactions on the accounts which typically require very little maintenance...if any at all. It is because of this stability plus the fact that IBM does do a good job of maintaining compatibility that COBOL code like this will continue to be in production systems at banks for long after
Re: (Score:2)
Re: (Score:2)
Can you implement blockchain in COBOL?
Here's where you can ask: https://www.ibm.com/it-infrast... [ibm.com]
Go ahead and ask . . . and then tell us how it went . . .
Stupid question (Score:3)
Re:Stupid question (Score:5, Insightful)
Stupid question here, but if big businesses are having all of their older, experienced programmers retiring and none of their younger programmers have the skills, why aren't they paying to train people that already work for them? Seems like that would be a lot easier and cheaper, plus they have the added bonus of already knowing what your business does/needs and how it works.
Why [ay to train when you can make vague promises to the under-employed programmers who then train themselves on their own dime. Hell, you won't even need to hire all of them, just the best 10%.
Re: (Score:3)
Better question: why aren't they rewriting this stuff?
This is technical debt, a particular type of risk that piles up over time unless mitigated by taking other risks. Technical debt occurs when you solve a problem with a less-than-optimal solution to avoid a cost--whether that be time, money, or risk. Time isn't a factor here; rather, it's expense (small) and risk (large).
Banks pay quite a lot for maintenance of these systems, and can afford redevelopment. It's not that they're loaded with money, b
Re: (Score:2)
Re: (Score:2)
Oh, you can architect software that way; it just takes one hell of a lot of investment. It's not so much expensive as it is time-intensive and procedural. This is where you use project management to the fullest, you have a real QA team, you have disaster recovery and hot sites, and all that. Those things are all products of risk decisions, and the requirements here dictate a large investment in risk mitigation.
This is the kind of system for which you produce architectural documents first; you build te
Re: (Score:3)
Staying power (Score:3)
Into what? COBOL has lasted 50+ years. How do you know Java or C# or Python will last that long (in viable numbers)? COBOL is kind of like Latin: it's stable because it's a dead language. Scientific taxonomies use Latin because it won't change on them.
COBOL also has a lot of built-in idioms for business data processing. Java etc. would have to use libraries to get similar, and those libraries may fall out of maintenance even if Java itself lasts.
Re: (Score:2)
COBOL hasn't lasted 50 years; it's an old legacy language that's running because people are still using it and paying huge money for it. MS-DOS still runs some POS systems.
You make a disjoint argument, as well: if something is so popular and powerful that it lasts 50 years, why would something else critically-important to large, super-rich clients simply fall out of maintenance?
Finally, C# is current, it's well-known, it's easily-maintained, it has modern OOP which allows extensibility and flexibility
Re: (Score:3)
Better question: why aren't they rewriting this stuff?
Because the actual requirements are pretty complex and easily underestimated. If you underestimate the complexity of a core system, the replacement project will be very expensive and could easily fail regardless of how much you pay. What makes it worse is these services shops like Accenture love big messy projects with vague requirements because they can make bank on the endless late game change requests that are necessary for the system to be usable.
It is not actually rare for big companies like banks an
Re: (Score:3)
Absolutely true. You implement systems like this in an incremental manner, with parallel deployment so you can thoroughly test. Basically, you form the foundations first, then begin building components, and create adapters to connect your existing system to these new components where they replace parts of the old one; and you run this stuff side by side, duplicating all actions so you can compare results from both systems. Each time you've sufficiently demonstrated a subset of components, you replace pr
Re: (Score:2)
Because employment is a short term thing these days.
Getting a job used to be like getting married. It wasn't unusual to get a job at a place (the mill, Big Blue, the bank) in your 20s, and retire from that place forty years later. People changed employers maybe three times in their career. The average today according to BLS is twelve, with the average duration 4.2 years, and the trend is toward even shorter term employment.
If someone is going to work for you for ten or more years, you might well invest i
not again! they don't want COBOL they want CICS (Score:5, Interesting)
oh, not again ... they do not want COBOL programmers, they want programmers who know CICS transactions and DB2, VSAM, etc, who have enough experience to come in and fix production business logic ... I see this article every year or two and it's ... let's all say it together ... NOT COBOL PROGRAMMERS ANYONE WANTS ... if you know COBOL but don't know CICS, you will not get a job... and, hey, there is a huge glut of out of work CICS experts to pick from.
Re: (Score:2)
there is a huge glut of out of work CICS experts to pick from.
Hmmm. Let's think about that for about seven seconds. "A huge glut", you say. That implies that many of the CICS experts who used to be needed have become redundant. (Even though many will have died or retired, considerabl;y diminishing the size of the pool).
How can that be unless many or most of the existing CICS systems have been retired? And, you know, they haven't - because no one has the time and money to recreate them.
There isn't enough money in the world (Score:2)
To make me go back to programming COBOL on mainframes. /h (maybe)
I did it for 3 years. I still have the 9mm scars as a consequence.
easy.. (Score:2)
Learning COBOL is easy (Score:2)
Anyone with some coding experience can learn it in a couple of weeks.
What's more difficult is that every single company has it's own editing/compiling tools, source management, home made subroutines, programming standards, etc...
Coding for batch processing is a lot different than for a web pages or user applications.
And forget about the documentation, it has probably been lost in all the movings and restructurations. Some systems are more than 30 years old.
It's a fadso! (Score:2)
These firms are on the hook for correct transactions, screwups of which can cost millions.
So if it ain't broke, don't fix it. Go away, refactoring busywork generator portion of latest software engineering strategy fad.
Not just COBOL (Score:2)
Where Do They Get Their Hardware? (Score:2)
But where do they get replacement hardware for mainframes and how secure are those supply channels? If it's going to take years to create a newer system, are the channels that provide replacement hardware guaranteed to be in place for the entire duration from the time a replacement project starts (let alone the time management continues to procrastinate in approving a replacement s
Re: (Score:2)
The truth is, nobody is really running on old mainframes. They are running on brand new mainframes, most likely ones that have been released in the last five years. The latest mainframe was released just 4 months ago. Mainframes are still in active development, with new models coming out every 1.5-2 years.
Re: (Score:2)
They get their new mainframes from IBM of course, which also provides repair parts. Many of them use IBM mainframes for which there is an upgrade path to newer mainframe models built on todays technology. This is the case with the z/OS stuff which originated as System 360. IBM prides itself in full backwards compatability, mostly the case that an app written in 1965 for System 360 should still run on a 2018 IBM mainframe. Upgrading to a new mainframe is a fine solution. mainframes are designed to provide h
In the Year 2000...... (Score:3)
Cobol programmers will be in high demand, in order to stop the Millenium Y2K bug
In the year 2018... the problem is still not fixed.
It's not about COBOL, it's about the ecosystem (Score:4, Interesting)
When people are saying they need people to fill "COBOL jobs" they aren't actually looking for COBOL programmers. There are looking for people who are willing to jump into excruciatingly painful dead-end jobs dealing with obsolete technology and working just to keep something afloat.
I had an internship with a Fortune 500 company (not a tech company) working on COBOL software in the late 1990s. The COBOL part was easy. It is a pretty simple (but verbose) language and doesn't take long to learn if you've seen FORTRAN, Ada, or BASIC. What *was* really hard was learning how the reporting and monitoring systems worked (we were basically gathering data from food production machines, reporting and archiving it).
Basically, everything in this division was run on old IBM mainframes (actually new mainframes/minicomputers emulating old operating systems... MVS and AS/400 or something). You didn't have a command line where you did your compile and link stuff... oh no, you had to submit jobs in a very finicky format using the mainframe's JCL (job control language). It was heavily customized for no good reason (that I could tell) so only a few of the really acidic and unpleasant old-timers could help you get your stuff going. You couldn't look this stuff up on your own because it was basically macros built upon macros from I'm guessing the early 1970s.
Anyway, this internship was soul destroying. Like the worst job I ever had. I worked my ass off and barely accomplished anything because the simplest thing was so hard and no one knew what the hell was going on. Every so often a "consultant" from HQ (we were a remote site in a different state from the headquarters) would come, install something, and then he (always a he) would leave while everything broke. Even though my internship was to develop a specific piece of new functionality, I spent most of my time figuring out what was going wrong and patching it.
So technically, I have COBOL experience now, but really I have a bit of experience bashing my head against a custom one-of-a-kind wall, and that experience isn't transferable.
To add insult to injury, it wasn't even a high-paying internship. The only good thing about this company was the culture was everyone was out the door at 4PM (hours were strictly 8AM to 4PM). Once I stayed to 6:30PM to fix a production server that was mangled by a messed up JCL card. (Oh god, the JCL cards. Of course they weren't punch cards because this was the 1990s, but you had to format the commands AS IF THEY WERE FREAKING PUNCH CARDS I guess because they were reusing old punch card parsing code. So, if you put a JCL mnemonic in the wrong column, the job failed. I wish I were making this up, I really do, but I'm not.) Anyway, I stayed till 6:30PM one night and the plant manager was so excited with my "can-do" attitude that he gave me a "golden nickel" which was one free lunch at the plant cafeteria. Yes, this was six months of my sorry life.
Fixed Point Math (Score:2)
Besides the hundreds of billions of lines of code that would need to be translated, COBOL does fixed point math exceptionally well which is why banks used it in the first place.
If developers are serious about replacing COBOL, they need to focus on fixed point math and then figure out how to make a compelling financial case for using it. Change for the sake of change is not a reason to spend the money to change a language.
https://medium.com/@bellmar/is... [medium.com]
My first prof programmer job offer was for COBOL (Score:2)
I tuned it down without any hesitation.
I had been working at a company whos draconian monolith called Data Processing Department had no clue how to run a manufacturing plant. We had asked for 6 years to have a report for a fully expanded bill of materials (supposedly an impossible task) for our products so we could get a jump on the purchasing and inventory analysis of long lead items, and yet we were stuck with the hand entry on paper, whch was hand typed twice by data processing operators, which generated
Re: (Score:2)
Someday, they will die out but for now they have a use!
The same can be said for *any* technical skill.
Re: (Score:2)
You're using COBOL, right?
Re:First? (Score:5, Funny)
IDENTIFICATION DIVISION.
PROGRAM-ID. FIRST.
PROCEDURE DIVISION.
DISPLAY 'First'.
STOP RUN.
Re:Repost (Score:5, Insightful)
I remember in about 1991 people were talking about how Cobol was "dead" and it would soon go away. I checked and found that over 100 billion lines of Cobol code were used in vital business systems every day.
In about 1995 there was another wave of "Cobol is dead". I checked the same sources and now it was over 200 billion lines.
Reality is that which doesn't change just because we don't like it.
COBOL Has Advantages (Score:5, Informative)
You can be a snobby all you want about your C and SQL databases, but one thing two combinations will never do is what COBOL does every night, weekly, etc.
That is process millions...I mean MILLIONS of records in a single night, producing bills, checks, statements, etc.
COBOL is optimized for record processing, not pretty pictures, drop down menus, HTML, etc.
COBOL has once focus:
1. Get the data in
2. Transform it
3. Get the data back out.
COBOL can slice and dice data in ways C and SQL can't even dream of.
You don't write Websites in COBOL. You do the serious work that involves billions of dollars of transactions. Reliably, repeatedly.
Re: (Score:2)
COBOL can slice and dice data in ways C and SQL can't even dream of.
But then again, so could almost any other decent general-purpose computer language.
(But without all that boilerplate and flowery prose syntax.)
Re: (Score:3)
Not the same way.
Read up on the Redefines features.
Slice and dice before the code so your code isn't cluttered with Mid, Left, Right, Strip, etc.
Re: (Score:2)
That's great if all of your strings are of fixed length, like in some kind of 1960s punched card stack.
Re:COBOL Has Advantages (Score:5, Insightful)
But then again, so could almost any other decent general-purpose computer language.
Depends but honestly, not really. I've worked C++, Java, COBOL and RPGLE. Most modern languages are general purpose like you said, and as such have to have libraries and what not added to them to make them SQL/Database/sockets etc aware. COBOL and RPGLE are pretty much specifically written to work with files/tables/transformations. Of course, the trade off is that those two languages become horrible for things outside that task.
Good example. In RPGLE database tables are files (actually the file concept came way before the table concept but I digress). You treat then just like you would any other file. Want a struct that matches the layout of a file (database table) you just define it to be like that file.
dcl-ds SomeStruct likerec( SomeRec : *all ) inz;
That's it. When you update the layout of the table, a quick recompile of the program updates the program too with no code change. You don't have to add getters, you don't have to add setters, none of that stuff that would be needed in Java or C++. If you want to store something from the database in that struct its
read SomeStruct SomeRec;
Change some values and then to update that changes back to the database
SomeStruct.SomeField = 'New Value';
update SomeStruct SomeRec;
COBOL is pretty much the same way except the op-codes are a bit more verbose as you indicated. Again, I'm not saying RPGLE or COBOL are better than C++ or Java or what have you. What I am saying is that they are languages that were developed for a very specific purpose and as such they are incredibly honed into doing that purpose quickly.
COBOL can slice and dice data in ways C and SQL can't even dream of.
I think that's a bit overselling it. Even the best COBOL can be emulated in C++, the catch is that somethings in COBOL are made a lot more complicated in C++. One thing is that COBOL has built-in understanding of how to build reports that will be printed. That's because COBOL was made to specifically address that kind of stuff so it's no wonder that in COBOL you can instruct a report to be printed with a single line of code. You can do roughly the same in C++ or Java but you're pulling in a ton of libraries to get that done.
Again, the folks who have used RPGLE and COBOL all their life, they'll swear by it. And I get it. For things like taking in massive amounts of records and doing the exact same operation on upteen billion records, RPGLE and COBOL cannot be beat because they were written to do exactly that. However, want to do some cool website UI? Yeah, RPGLE and COBOL are horrible choices to do that in. Want to do some sort of RESTful API? .NET/Java/Shit probably an abacus are all going to be way better choices than RPGLE or COBOL. The two are very, very specific languages in what they will and won't do, and processing billions upon billions of records like Charlie Sheen processes lines of cocaine, is exactly what these languages have had the last four to five decades to refine. You'll be incredibly hard pressed to find compiled output that matches their speed, that used a HLL outside of them.
Re: (Score:3)
It's even got a built-in cycle, you don't have to tell it to READ a file, that's what it'll do when you give it a file name
Indeed the cycle is still there for OPM, but if you want ILE you have to ditch the cycle. OPM biggest use is exactly what you said, if you want to batch process a massive load of records. Where I'm at there's still some programs that use cycle because we load up data sent in from all the branches, doesn't matter if the file is 1,000 records or 100,000,000 records the batch for each branch is so quick the timing is considered to trivial.
Now, getting it to process things interactively, like a terminal screen
That gets more into where you'd used ILE to break things up into piece
Re: (Score:2)
COBOL's greatest advantage over C and its decedents is no IEEE 754, floating point arithmetic "issues." Granted the precision may be viewed as "negligible," but not for penny pinchers. Now, the problem with the precision is taxed on the programmer to do their math/algorithm correctly.
That's only seen as an advantage because accountants are such decimal chauvinists.
It there were 64 cents in a dollar, they'd have no problem with IEEE 754 math, since any errors introduced by the algorithm would be the exact same errors they would get by doing the problem with paper and pencil. (They want to see familiar errors, not unfamiliar ones. The familiar errors are defined by accountants to be "correct".).
Re:COBOL Has Advantages (Score:4, Interesting)
Re: (Score:2)
You do the serious work that involves billions of dollars of transactions.
Meh. A slow day on Wall Street. What do the big exchanges use? Learn that. Probably not a batch oriented language and underlying system. Something that can support event-driven high frequency trading.
Re:COBOL Has Advantages (Score:4, Funny)
That's the funniest thing I have read about software since the IT director who was quoted as saying, "We're going with XML because it's the fastest Internet protocol".
And that wasn't Dilbert - that was real life.
Re: (Score:2)
Re: (Score:2)
Don't pretend every bank has decades old mainframes.
No - just the ones whose systems work reliably and consistently, and don't have regular catastrophic "IT outages".
Ever heard the definition of a "legacy system"? One that works.
Re:Most prevalent? No. (Score:5, Informative)
Re: (Score:2)
Where does this STUPID idea that mainframes are 'decades old' come from? Of course these companies replace hardware. They spend MILLIONS of dollars doing it, and they do it every few years. And what do they replace it with? NEW mainframes, because they are best suited for the job. The latest IBM Z mainframe was released 4 whole months ago.
Re: (Score:2)
Re: (Score:2)
Don't pretend every bank has decades old mainframes...
You're right - many of them have fairly new mainframes. Running the same software.
(hint: guess what most web banking firms have to keep writing connectors for, even today?)
Re: (Score:2)
Re: (Score:2)
Know any PDP/11? https://www.theregister.co.uk/... [theregister.co.uk]
Re: (Score:2)
DEC went belly up a couple of decades ago... PDP-8 went out of favor for the PDP-11, then the VAX-11 did that in with the thumb switches on the thing.
I'm with you though, I wonder if my DEC VAX Administrator training certificates are worth anything more than for starting a bonfire, or my demonstrated ability to adjust the boot loader for the Harris H100 to use the correct CDC 300 Megabyte 8 platter Drive to boot Vulcan is a marketable skill. Somehow, I'm guessing not.
Re: (Score:2)
Yet the PDP-11 lives on. In the '90's and early 2000s in the form of the Osprey, a PDP-11 on a PCI card. Now, software emulators are fast enough.
Use marketing BS (Score:2)
Banks don't want to pay for training, they want plug-and-play staff, and a pony.
Perhaps they should rename it to sound hip and cool. Stupider things have caught on*. Call it Cloudbol++ or node.bol or Bolockchain.
* Or applied to the wrong things or places
Re: (Score:3)
I haven't seen anyone offer a training, boot camp or workshop in COBOL.
Because you did not look for it.
Google: cobol workshop
About 832,000 results (0.35 seconds)