Major Banks and Parts of Federal Gov't Still Rely On COBOL, Now Scrambling To Find IT 'Cowboys' To Keep Things Afloat (reuters.com) 300
From a report on Reuters: Bill Hinshaw is not a typical 75-year-old. He divides his time between his family -- he has 32 grandchildren and great-grandchildren -- and helping U.S. companies avert crippling computer meltdowns. Hinshaw, who got into programming in the 1960s when computers took up entire rooms and programmers used punch cards, is a member of a dwindling community of IT veterans who specialize in a vintage programming language called COBOL. The Common Business-Oriented Language was developed nearly 60 years ago and has been gradually replaced by newer, more versatile languages such as Java, C and Python. Although few universities still offer COBOL courses, the language remains crucial to businesses and institutions around the world. In the United States, the financial sector, major corporations and parts of the federal government still largely rely on it because it underpins powerful systems that were built in the 70s or 80s and never fully replaced. And here lies the problem: if something goes wrong, few people know how to fix it. The stakes are especially high for the financial industry, where an estimated $3 trillion in daily commerce flows through COBOL systems. The language underpins deposit accounts, check-clearing services, card networks, ATMs, mortgage servicing, loan ledgers and other services. The industry's aggressive push into digital banking makes it even more important to solve the COBOL dilemma. Mobile apps and other new tools are written in modern languages that need to work seamlessly with old underlying systems. That is where Hinshaw and fellow COBOL specialists come in. A few years ago, the north Texas resident planned to shutter his IT firm and retire after decades of working with financial and public institutions, but calls from former clients just kept coming.
Milk Them (Score:2, Interesting)
I hope all these COBOL programmers are smart enough to charge outrageous rates. Minimum $250/hr.
They've got the banks over a barrel, any time the situation is reversed the banks don't hesitate to screw us.
Re: Milk Them (Score:5, Insightful)
Re: (Score:3)
Re: (Score:2)
Quite likely they did. On the other hand you mussed have been sick the days they talked about "reading comprehension"
Re:Milk Them (Score:5, Interesting)
I hope all these COBOL programmers are smart enough to charge outrageous rates. Minimum $250/hr. They've got the banks over a barrel, any time the situation is reversed the banks don't hesitate to screw us.
$250 per hour is a pretty normal rate for an experienced professional, hardly outrageous at all. When I worked for IBM Global Services, they billed me out at $300 per hour. Granted that IBM commands a premium due to their marketing channels, but I'm sure I could have gotten $200 per hour on my own and my expertise is far from as rare as deep COBOL experience. I'd expect people like the one mentioned in the article to cost more like $500 per hour, if they're actually aware of their own worth, and I wouldn't consider even that outrageous.
If I were in the position of those programmers, I would probably try to avoid quoting an hourly rate at all. Instead I'd do it all as piece-rate work, based on detailed specifications -- especially if I'm working on a system that I know, so I have a good idea of what sorts of obstacles I might run into. Then I'd try to set my price based on the value of the work to the business, rather than on the time it would take me to produce it. That could easily result in contracts that work out to many thousands of dollars per hour.
A friend who is a lawyer told me that the best piece of career advice he ever got from his father, also a lawyer, is "Take the money, son." He didn't mean to take money for unethical work, but just that one shouldn't balk at accepting high fees just because they seem too high. If the customer is willing to pay, take the money. That attitude should absolutely be applied to doing contract work for banks.
Re: (Score:2)
That seems to be right - experienced Cobol developers are rare these days and you can't get them when you need them so you better have a thick wallet. And banks have thick wallets.
Since I work with a large company the price for a small change like creating a new report is about $100 to $500k. And that's a list that could be thrown together at a coffee break in Java.
Just offer more money (Score:5, Insightful)
Any good programmer can learn to program in COBOL given enough financial incentives.
Re: (Score:2)
Indeed. Probably the easiest language I ever had to learn. I'm sure I've mostly forgotten it now because I've never used it since I learnt it in University (besides converting some old Cobol to VB6 a long time ago... but that was reading not writing).
Re:Just offer more money (Score:5, Interesting)
Easy to learn, fairly easy to read. However, the Lords of Cobol are masters at programming in a way that most people today can't think. it is a quite literal programming language.
Re: (Score:3)
Re: (Score:2)
Been there, did that, but with VFP6, which is also a dead language.
Re:Just offer more money (Score:5, Insightful)
Re: (Score:3)
I agree. I haven't even "learned" it but I was able to contribute to fixing a project that had it. In 2012 at a major pharmaceutical company merger I got tired of being told some mainframe cobol thing was working one way and seeing it work another. So we finally did a live code walkthrough and I easily spotted the logic error that was causing the actual behavior. Granted this COBOL was written and structured about as well as COBOL could ever be, but in the end it's just another set of terms and syntax to learn.
More than that, COBOL has far fewer features than any modern language, making it even easier to figure out what's going on. If you know any computer language you can easily determine exactly what 99% of all COBOL programs are doing simply by looking at them. That doesn't make you a COBOL programmer, but it's not like Ruby where you really have to know the language to a pretty good extent to figure out what a block of code does.
Re: (Score:3)
This.
I took COBOL and it was one of the easiest to understand.
The goddam language is almost English. Fuck, I never had to "press 2."
Mr. Hinshaw needs to be teaching a bunch of COBOL graduates.
Re: (Score:3)
COBOL (Score:3)
Re:COBOL (Score:4, Interesting)
I supported several apps based on Microfocus COBOL and so-called Visual COBOL. No significant problems with either platform, the apps worked as well as thne programmers did, or more correctly, bugs happened. One was rock solid, the other had predictable issues with every major release that were resolved without much delay.
Stereotyping COBOL is inevitably just age discrimination. It's functional, as the history and current situation proves. It's a language, competent programmers that have progress from C to C++ to Java will figure it out if they see profit in doing so. I work with an old-school COBOL programmer who has no patience with the young whippersnappers who whine about every problem a legacy platform presents. There is so little interest around here to abandon the core transaction systems that claims that COBOL is 'obsolete' fall on deaf ears. They train new maintainers here. What a concept, training your team! Gah!
Re:COBOL (Score:4, Interesting)
Re: (Score:2)
I worked for a company 20 years ago that had a Windows program written in VISUAL COBOL. It was terrible. It crashed all the time. When it worked, it was slow. We don't need more COBOL programs, but I hardly think that Python is the answer.
I imagine the failure modes revolved around the words "Windows" and "Visual" rather than "COBOL". As other posters have pointed out, running real COBOL on grown-up, production hardware like IBM System z, etc... is a better metric.
Re:COBOL (Score:5, Funny)
Is there any programming language with "Visual" in the title that's worthwhile?
Re: (Score:2)
Re: (Score:2)
Sad thing is, I wasn't really joking when I asked. Only "Visual"-titled languages or environments I was familiar with were Visual Basic and Visual C++, and at the time I was exposed to them I did not care for them.
Yearly Article/Cautionary Tale (Score:5, Insightful)
Ever since I first joined /. there has been an article a year stating:
- Major organizations, banks, governments, etc. are still relying on COBOL.
- COBOL programmers are in great demand so dust off your old MVS skills (and maybe pull out those JCL manuals) and offer up your services, you're in demand!
What I really think is the big takeaway from all this is simply that the need for supporting for your old software is never going away - so think of a way of monetizing it.
Re: (Score:2)
The language isn't the issue (Score:5, Interesting)
Re:The language isn't the issue (Score:5, Insightful)
Except the linked article specifically notes that the 75 year old's company is a group of 20 or so "code cowboys" who parachute in to fix systems they have no prior knowledge of and get paid $100/hr for the pleasure. So it would seem deep understanding of the language and the ability to troubleshoot bad code in said language is indeed the crux of the issue.
Re: (Score:2)
It could be both. Bad code can be written in ANY language such that COBOL itself is not necessarily the direct problem, but rather mis-use of COBOL by the original-but-gone staff. If the original code was in say Java or Ruby, it too could have been sloppy code, leading to the same problem.
And if there are no domain (subject) experts around, then the organization may
Re: (Score:2)
Re:The language isn't the issue (Score:4, Informative)
> The only barrier to entry preventing some millenial from learning COBOL is the lack of consistent jobs maintaining COBOL code
Actually, no. There are plenty of jobs at unexciting companies for long term full time COBOL programmers. The company I work for, for example is constantly looking to backfill retiring COBOL programmers in one of the financial divisions. To be honest, if I had to do life over again I'd seriously consider picking up COBOL 25 years ago as the wage and job security at those big companies for that position are great - no offshore outsourcers do COBOL, and even if they could, many of the systems involved are sensitive financial systems so outsourcing that could be a big legal minefield so no company wants to risk it. Plus the added little bonanza of the whole Y2K thing where COBOL programmers were making INSANE money in the year leading up to it - like $200/hr insane. In 1999 dollars as well.
Re: (Score:3)
Depends if they're actually travelling or just remoting in. If they travel I would expect accommodations are paid for as well as food and other expenses on top. And if you're doing 40 hours a week steady of that $100/hr contracting you're making close to 200K US per year. That's not bad no matter how you look at it.
Re: (Score:2)
Depends if they're actually travelling or just remoting in. If they travel I would expect accommodations are paid for as well as food and other expenses on top. And if you're doing 40 hours a week steady of that $100/hr contracting you're making close to 200K US per year. That's not bad no matter how you look at it.
As a contractor, you're also paying the "employer's" share of Social Security, as well as buying your own health and life insurance. Those two items alone were worth about $25K untaxed to me last year, and I don't make anywhere near $100/hr. Other things to consider when comparing captive vs. consultant compensation: paid holidays, paid vacation, and 401(k) matching. Accommodations might be provided if travel is involved, but this doesn't represent savings unless you're not also maintaining your regular res
Re: (Score:2)
If you read the article, it seems these contractors work for the 75 year old guy's company so they're probably actually employees in some fashion, just the work resembles contract work, and they get $100/hr for it. I'm sure the company in front of it charges considerably more than $100/hr to assign these guys to the jobs which all you mention is no doubt paid for out of.
Re: (Score:3)
I took $25/hr after the dot-com crash just to survive because the West Coast was flooded with out-of-work developers. My skills in legacy products saved my arse because web-only newbies didn't have those skills. IT pays well now, but keep in mind bleep happens and the future is unknowable. War, tech bubbles, recessions, offshore-enabling tech, crazy leaders, etc. may slap IT hard. Have a rainy-day fund.
Re: (Score:2)
Indeed it's not just the language - it's exceptionally verbose and you're hardly likely to misunderstand the meaning of "MULTIPLY NumA BY NumB GIVING NumC."
Partly, it's about understanding the way data is encoded (which is likely to be packed decimal or ASCII/EBCDIC numeric characters) but when people say "COBOL" they're often referring to code that's intricately linked (possibly through embedded macros) to legacy transaction-processing systems (like CICS) or legacy CODASYL (network-model - as opposed to re
Re: (Score:2)
Some of us actually thrive doing this sort of work. Rewriting working code is such a lazy cop-out.
Re: (Score:2)
This is the issue.
I won't go into more details as I'm writing analysis software for these type of systems (iSeries/AS400 rather than Z/Big Iron).
Re: (Score:3)
Cost is only part of the reason why replacement projects are avoided. Another major reason is the risk involved. Software developed in the 60s, 70s or 80s couldn't rely on many things we take for granted these days. Requirements engineering, robust libraries, development tools, testing mechanics and so on (warts and all) just were not quite there yet or did not exist at all.
Re: (Score:3)
This.
In my experience, inheriting legacy apps is very difficult because there's a steep learning curve before ever touching anything.
To fully grok the application, I had to read and understand and become the past programmer(s) so that I could predict what and how the program worked as the program pointer zipped along.
I could recognize different programmers by the signature coding approach in each module.
Then there's my world view, which I used to reshape the whole goddam thing.
Coders before me never documen
Re: (Score:3)
Actually it is much, much worse.
In the 1960's and 1970's compilers, and particularly COBOL compilers, were very expensive. They could easily cost more than a decent home.
This produced an interesting business model where a few programmers who happened to own a compiler would write custom software for various businesses. When the business wanted their software modified, they could contact the original authors and pay them to make the changes. Nice business model with a nice lock-in, The problem was that s
Re: (Score:3)
Funny story, I worked at a legacy code place where programmers never wrote decent comments.
Being naive, I thought, oh that is strange, I'll do better on my code and write some nice comments to help direct the next guy using this piece of code. After submitting my code to my superior for review, you would have thought I just stole a mainframe from the company. I evidently committed a quite nasty sin, and one that I was careful not to repeat again. But I got out of that place as soon as I could.
My experi
Re: (Score:3)
"Major Banks and Parts of Federal Gov't Still Rely On Cagey Programmers Who Never Write Decent Comments To Support Programs Instead Of Hiring People To Write Decent Comments."
It's not so much "cagey programmers" as it is over-worked programmers, especially at the State level, where computer illiterate legislators continue to dream up new legislation that puts pressure on coders to modify existing software to meet the legal demands. Except for management, most of whom are computer illiterates as well, S
Where? (Score:2, Informative)
Every year I see articles about how COBOL programmers are in high demand and companies are scrambling to hire them. But I learned COBOL and liked it and regularly keep my eye out for COBOL jobs. In the past 15 years I have seen a grand total one one COBOL placement within 1,000 miles. I call BS on the article, the local job boards are all for Java, C++, mobile languages and PHP. Not a COBOL position in sight.
Re: (Score:2)
I suspect that most entities that look for this kind of service don't post it in this way. Financial institutions in particular seem to play their cards close to the chest, they probably work with specific hiring agencies or headhunters to fill positions and don't just post them openly.
Re: (Score:2)
It also means longer-term thinking than just next quarter or next year. When corporate officers and even board members don't necessarily stick around for more than a couple of years to pump-and-dump the company, it's hard to get any kind of long-term planning done.
Re: (Score:2)
Re: (Score:3)
mainframe programmers were in high demand
Sort of - but somehow, in spite of the "high" demand, mainframe programmers don't command much pay. As in, I have about 5 years of mainframe (COBOL, JCL, Adabas Natural) programming experience, but I clawed my way out of it into desktop C++ programming just so I could make enough money to actually afford a car payment. If I went back to it now (from my current "enterprise Java" role), I'd probably take a 50% pay cut.
Re: (Score:2)
Creimer was the only one savvy enough to realize, the question was not meant literally, rather the old Jap was fishing for blowjobs. Later that day, creimer the fat oily youngster met the slender old man in the men's room, where creimer received his reward of a mouthful of lethargic elderly jizz.
Why are you trolling me? Is your life that meaningless?
Re: (Score:2)
Every year I see articles about how COBOL programmers are in high demand and companies are scrambling to hire them. But I learned COBOL and liked it and regularly keep my eye out for COBOL jobs. In the past 15 years I have seen a grand total one one COBOL placement within 1,000 miles. I call BS on the article, the local job boards are all for Java, C++, mobile languages and PHP. Not a COBOL position in sight.
You're obviously not a part of the Order of the Secret Knights of COBOL. The OSKCOBOL cabal keep all those lucrative COBOL jobs hidden from prying eyes of interferers. Let me know when you know the secret handshake and we'll open up the cushy job market of $500,000 per anum COBOL jobs to you.
I remember from the early 90s. (Score:2)
"You will get no course credit for COBOL, but you might want to take the class so you can get a job between semesters"
Few of us did (and I wasn't one of them), but those that did always had jobs come summer while a lot of the rest of us didn't.
Re: (Score:2)
Crying wolf (Score:2)
Why Not? (Score:2)
Re: (Score:2)
Why not use a program from the 50s and 60s?
The mainframe are probably from the 50's or 60's.
Don 't you want to make America great again?
Scrape the Old Iron and buy New Iron from IBM! No one ever got fired for buying IBM.
Re: (Score:2)
Does your supply chain utilize Lenovo Group Ltd (To include its subsidiaries: LenovoEMC, Medion AG, Stoneware Software, Motorola Mobility, NEC, Nok Nok Labs, and IBM PC Division) manufactured or produced Information and Communications Technology (ICT) products, including Hardware, Software, and/or Firmware components
Re: (Score:2)
About IBM...well, that's only IF you didn't buy anything from a division that got spun off to China. This question, concerning the Missile Defense Agency supply chain came in late last year:
I was thinking of IBM of yesteryear. That particular division, IIRC, was the PC/laptop division that went to China.
My assumption is that it's a recognized fact that PLA Unit 61398 and others have infiltrated the above companies. This is coming straight from General Dynamics, and imposed by the DoD.
Doesn't surprised me. When I worked at Google in 2008, they found backdoors in the BIOS for the newer Lenovo laptops and were planning to move away from Lenovo. I didn't see any Lenovo laptops when I worked there on contract in 2011.
Re: (Score:2)
Far more likely the mainframes are less than 5 years old.
The main application at my government IT job is 40+ years. The mainframes are a bit older than that.
But you can keep being stupid if you want, it suits you.
I'm not the one with an uninformed opinion.
Re: (Score:2)
I call complete, 100% bullshit. The software may be that old. The hardware? No fucking way.
Why is this hard to believe? We got B-52 bombers that are still flying since the 1950's and could fly another 50 years if the Air Force can't develop a new bomber that doesn't get jammed on its own radar jammer (B-1) or can't fly in the rain (B-2). Heck, when the navigational computers reboot on the B-52, the pilot just breaks out the slide ruler and maps.
Tell us exactly which 'government' this is, and what department, so we can expose your idiocy.
The three-letter agency I work for is classified. :P
"scrambling" is not the full truth... (Score:3)
They are having trouble finding people AT THE REQUESTED PAY, they are looking to pay chump change of $30K
Multiply the pay you are asking by at least 6 and you will get a Cobol programmer within hours. If you use something outdated and rely on it, then be ready to pay extremely well to get someone that is an expert in it. Most anyone I know that is a Cobol guru wont even bother to apply for something under $150K a year.
So if they really wanted someone, they will increase the pay and benefits to entice a person to actually apply. Sadly this basic element of business is lost on todays morons that are "leaders" and "managers"
Just $100/hour??? (Score:3)
For the specialization and demand that the COBOL work offers (not to mention the familiarity with how to use the tooling and platforms that surround those systems!) the people should be asking for a minimum of $500/hour.
After all it's all large financial institutions that are brimming with money, and like the said literally billions of dollars flow through these things every day.
So if you are out there and you know COBOL I would double your rate today. If anyone asks just say that a number of people you knew who did COBOL contracting all just retired and so demand is through the roof.
People don't WANT to maintain COBOL (Score:3)
People would be happy to learn COBOL in school if it did not suck the life out of people that touch it. And now that the only remaining jobs are maintenance ones, there is even less incentive.
And then there is Logo (Score:2)
Funny thing though (Score:3)
No surprise there (Score:2)
My COBOL story (Score:2)
I'd like to begin by adding that an experienced programmer (let's say somebody with over a decade of experience) should be able to pick up any language. If you have been exclusively using one programming language for your entire career including college, then you must be one in a million. Most programmers that I encounter have picked up dozens of languages and syntaxes over the years. When I received my first royalty check for programming in 1987, I was programming a Commodore 64 in BASIC with as little mac
I was a COBOL dev (Score:2)
These institutions screwed loads of us after Y2K so I'm highly amused to see them panicking. They'd have to offer me vast sums of money to go anywhere near them now.
Re: (Score:3, Insightful)
Java, C, and Python are newer and more versatile than COBOL. I fail to see your point. Yeah, some are old, but COBOL is the oldest, so the sentence is still correct.
Re: This is really funny stuff! (Score:4, Interesting)
Re: (Score:2)
A sentence can be technically correct yet still reveal the writer to be an idiot... sometimes in subtle fashion that other idiots wouldn't necessarily pick up on...
Thanks. That explains why some Twitter feeds are popular.
Re: (Score:2)
I think being amused by their creation dates is pedantic.
What the author was trying to convey is that COBOL is a dead language,
It seems that billions of dollars would disagree.
memory allocation errors, gone. (Score:5, Interesting)
One of the nice things about f77 and i presume cobol is that memory is allocated in a fixed way at compile time. so no mallocs and no deallocs and thus no null pointers. string buffer sizes are known. and relatively speaking, its harder to find cases where typos are not also syntax errors. for exapmle typing = instead of ==.
now for many things this memory issue is the pits which is why we like those other laguages. it makes object oriented styles impossible though for a fixed maximum number of objects you can fake it. but for a lot of things its all you need. and the block memory structures of multi dimensional arrays make data contiguous in memory and enable very efficient parallel optimizations. so there are advantages to giving up features.
if you are wanting very reliable code its not a crazy choice,
Re:memory allocation errors, gone. (Score:5, Interesting)
Everything in life is a tradeoff.
When the developer avoids allocation headaches by using fixed-sized strings and data structures, users are often saddled with arbitrary truncations and the need to make up funky abbreviations all throughout their data sets. This can be a major source of errors in itself.
Re: (Score:3)
blocks allocated by malloc are of fixed size, there is nothing new here
Wrong. The size of allocated blocks are typically computed at runtime to match the needed length of the input data. That's a big difference from defining some fixed-size buffers at compile time, then hoping or forcing all of the eventual input data to fit.
Re: (Score:2)
Why don't they automatically translate them to something more modern then run them in the cloud?
Maintaining these systems is just throwing good money away. Money that we all end up paying via our bank charges.
Re: This is really funny stuff! (Score:2)
Because COBOL can't run in the cloud?
COBOL is an efficient, practal tool to solve basic business application issues, it is primarily used on batch workloads and 'green screen' mainframe applications.
Rewriting applications that work flawlessly today into a new language, DB, and OS environment opens up what was a stable application to almost unlimited numbers of software issues.
The real migration path off custom CO
A-Fucking-Men (Score:5, Insightful)
COBOL is the Caterpillar D11 of data processing.
When you need to process millions of records reliably and constantly, a correctly constructed COBOL solution is robust, maintainable, and reliable.
COBOL doesn't and shouldn't give a shit about drop downs, java, PDFs and all that other bullshit. It's is doing the heavy lifting that C, Java (don't make me puke), and all these other supposedly superior languages can't do.
Eye Candy has nothing to do with making sure 50,000 employees get their checks every week or millions of SS recipients get their checks every month.
And the best thing, it's not rocket science...by design. A single semester of COBOL can get someone up to speed to the point where they can maintain everyday COBOL applications. When things get crazy, it's not the language that's the roadblock, it's just the normal analytical skills.
Re: (Score:2)
Amen to that.
I was once tasked to get some data from the mainframe into the DWH I was building. We had an external COBOL programmer come in to do this because the rest was busy on fixing Y2K and doing the Euro implementation. His program was repeatedly returning really incorrect data. But no problem: I just printed out his program and pointed out all the bugs: yes, Cobol is so easy to read and debug that even without training I could just follow the flow of the program, see what it was doing and where it wa
Re: (Score:3)
It's not the COBOL per se, but how it runs and integrates into the system.
The expertise comes in making files available to read and write output to.
In my post below, I noted that if you're running in MVS (old IBM iron), you need to know and be comfortable with JCL. Same thing for VMS.
That's where the grey hair comes in.
Re: (Score:3)
Think of Joel Spolsky hiring C++ programmers because they can reason deeply how code works and then he puts them in front of Visual Basic 6 to pound out his application because they don't have to fiddle with MFC to get the GUI part?
Well, what's wrong with that? I was a C++ programmer throughout my education and my first job as scientific programmer, and moved on to VB6 and then VB.Net. Double the pay for half the effort, what's not to like :) And in the end it's all just a Turing Machine anyway, we're just debating the syntactic sugar as long as we stick to imperative languages.
So nowadays I just use the tools that make it easiest to code and test a solution, not the tools that are generating the most work for everyone. For most appl
Re:This is really funny stuff! (Score:4, Interesting)
Why don't they automatically translate them to something more modern then run them in the cloud?
Maintaining these systems is just throwing good money away. Money that we all end up paying via our bank charges.
Translate debugged, working, proven code into something else? Not really a good strategy for production code. I also doubt that maintaining those systems is a problem or limiting expense. Modern hardware can run COBOL just fine. As TFS implies, the expense is in finding and hiring people trained in (or willing to learn) a language many don't see as useful and/or sexy -- mainly 'cause it's old. Newer / younger isn't always better or less expensive
Re: (Score:2)
It's a good strategy, and carries different and more-immediate risks. It's an attractive option for me because it allows factoring in new lessons-learned and it makes risks controllable: old COBOL code might not respond well to new requirements, and will eventually need to interface with new code--either new COBOL code or new code in some other language. You can't control those risks as well as you can control an elective rewrite, because the risk of new requirements is often surprising and under time-p
Re:This is really funny stuff! (Score:5, Insightful)
'Eventually COBOL will need to interface with new code...' Eventually? Do you suppose these programs had support for EFT, ATMs, bank-by-phone, online banking, mobile apps, etc when they were written 50+ years ago? You're not going to scare them with 'Oooh - there could be a new requirement!'
When you say rewriting is a good strategy, do you have ANY idea what that entails? You are not just talking about a few COBOL modules here and there. You are talking about potentially changing the ENTIRE system. Your COBOL program is probably running under CICS. The hardware CICS and your program have been running on have been optimized for your workload. Your data is probably stored on ECKD DASDs. Your data is probably stored in packed decimal format, so it can be operated on with a single, optimized, machine instruction.
Now, you want to 'rewrite' it. OK, where do you start? If you just replace your one COBOL module with some other language, does your 'new' language natively support the data you are operating on? Does it support the types of datasets you are using? Does it do those things with the same performance characteristics as COBOL? Does it properly and efficiently interface with CICS?
Your last paragraph is laughable. These 'old' systems are 'chewing-gum-and-tinfoil' unreliable systems? Oh yeah? When have you heard of one of these systems failing? When have you heard of security breeches involving these systems? And before you incorrectly say 'airlines', I will point out that NONE of the recent airline outages involved the mainframe portion of the operation. It was the 'new, better' stuff that falied in every case.
Re: (Score:2)
10/10 trolling, got a reply :)
Re:This is really funny stuff! (Score:5, Funny)
It never occurred to them because they're not anywhere near as smart as you.
Re:Translator (Score:5, Interesting)
COBOL has been around long enough to be a victim of featuritus. I has a lot of built-in operations and short-cuts that are great if you know them, but could trip up a newbie.
But the hard part of a typical COBOL job is probably learning your way around many thousands of lines of existing programs. I've always found writing code simpler than reading code written by somebody else, especially if it's poorly structured, documented, commented, etc.
The language and syntax the business logic is written in is secondary to that issue. Readable code can be written in any language, but so can crazy pasta.
Re: Translator (Score:3, Interesting)
Correct. I've been a COBOL gun for hire for 15 years, mostly in finance, and the rubbish you have to get your head around sometimes is amazing. On the flip side I've seen some very clever things too.
Once I had to fix a nasty bug in a clearing system causing dropped transactions; took me a day of scrutinising thousands of lines to find the logic error.
Largely it is actually all being phased out though, contrary to this article. There were times I could have $3000/hr contracts, they're much less frequent thes
Re: (Score:2)
"featuritus" ??? What's that? Is it like featuritis? -itis, as in a disease?
Nice try. -itis indicates inflammation; -osis indicates disease. -itus sometimes shows up as the suffix for a medical condition, such as tinnitus (ringing in the ear); this may have been what led the OP astray, though it was probably just a typo.
Re: (Score:2)
It's not just a random computer language, it has quite a bit of intricacies and used to be geared towards solving business logic problems. It also has numerous dialects. Additionally, these programs are often huge and nobody knows for sure what test cases need to be applied, so even if you could translate and then write the amount of tests for the logic that has evolved over 30 years you might as well just rewrite it which is the cost they're trying to avoid.
The problem is not necessarily the software that
Re:Translator (Score:5, Interesting)
Haha! IBM is making a 'killing supporting old systems'? IBM comes out with NEW mainframes about every two years. The current system (z13) is from all the way back in 2015. And you won't find 'better hardware' anywhere. Cheaper? Certainly. Better? No.
Re:Translator (Score:4, Insightful)
Yeah. "All You Have To Do Is..."
Think about human languages. Translate "Out of Sight, out of Mind to a language like Chinese, where a literal conversion might be "no-see, no-think". Now take another automated translator and translate it back: Invisible Idiot.
Every language - computer or human - has its unique characteristics. There's an old saying, in fact that "Translators are traitors".
Case in point: COBOL didn't support variable-length strings. Most modern languages have little or no tolerance for fixed-length strings. IBM COBOL supported a hardware-level data type (COMPUTATIONAL-3) which can store penny fractions precisely. Most modern languages don't allow for that, and tend to use floating-point (COBOL COMPUTATIONAL-2). Which cannot store decimal values precisely. Fuzz the pennies on people's paychecks and see how long before the torches and pitchforks come out. It's one of 2 reasons why so many payroll and accounting systems are written in COBOL (with the other one being that there's not exactly a lot of leading-edge technology in basic financial systems).
Some of these things can be automatically dealt with - albeit with some inefficiency - some of the more subtle issues have to be dealt with more directly, just as we've never yet managed to construct truly generic software-writing systems and have to continue to use programmers instead of robots like we do with truck driving and day-trading.
I have, actually worked with/supported automated code translation projects using commercial translator products. Every one of them has required a time and manpower budget for the clean-up crew. You can get about 80% of the job done automatically (although the resulting code may look horrible to a native human programmer). But to get something actually working, the tools need human help.
Re: (Score:3)
You mean like how every modern database supports fixed point decimals and how every language has a type for them in their standard library (or some third party one)?
Re: (Score:3)
To some extent true.
I have messed around with Cobol a bit and even though it's a pretty stable solution when you work with it there are some stuff that it suffers from, and it's primarily that it has a hard time to interact with other systems once you get the data into a Cobol file. A file written with Cobol should only be read by Cobol and any data sent to a Cobol system must be written in fixed record format where every position is important. Negative numbers is a creature all of their own since some Cobo
Re:Translator (Score:4, Informative)
I started programming in COBOL in 1978. I spent a decade or so on IBM mainframes with COBOL and 370 assembler.
I never referred to anything as a COBOL file. There were many types of file and database structures on IBM mainframes. While many simple systems used fixed record formats it wasn't nearly always the case.
The FILE section of a COBOL program allowed for varying record sizes:
FD file-name
RECORD IS VARYING IN SIZE FROM small-size TO large-size DEPENDING ON size-variable.
WORKING-STORAGE SECTION.
77 size-variable PIC 9(5).
The language also allows for the redefinition of record layouts so the type of data and what is to be done with it can be determined at run-time.
Re:Doesn't surprise me... (Score:4, Funny)
I mean, everyone knows that Ethernet uses the second and third pairs on an 8P8C jack, while Token Ring uses the first and second pairs. If they wanted to get it right they needed to just connect pairs 1 to 2, and 2 to 3, or if crossover, pairs 1 to 3, and 2 to 2...
Re: (Score:2)
I mean, everyone knows that Ethernet uses the second and third pairs on an 8P8C jack, while Token Ring uses the first and second pairs.
The building was five years old and wired for Ethernet. The financial institution had it wired for coaxial because of the coaxial switches in the network closet. I guess it was cheaper to roll out coaxial cabling than buying new switches for twisted pair cabling, as the Token Ring NICs could take either coaxial or twisted pair.
Re: (Score:2)
On a more serious note, the cost to wire versus the cost for switches really depends on the number of drops, the relative port-capacities of switches to those cable counts, and any backbone (ie Fiber) costs needed.
Token Ring using the shared medium on each literal token ring segment allows for more nodes per segment than modern Ethernet with the mindset that two devices are a collision domain and thus one switchport per device is necessary. I haven't made a study of token ring so I don't really know how ma
Re: (Score:2)
On a more serious note, the cost to wire versus the cost for switches really depends on the number of drops, the relative port-capacities of switches to those cable counts, and any backbone (ie Fiber) costs needed.
The conversion project was for 500+ workstations at that one branch office. Not sure how many branch offices were involved when the switchover to Ethernet took place at the NYC headquarters. I spent four hours waiting for NYC to turn on the switches from their end, four hours to do 250+ workstations by myself, and four hours to fix 250+ workstations that youngers messed up by not following directions. Finding a cab at 3:30AM was not fun either.
Re: (Score:2)
Smells like bullshit. Must be creimer. It is. It is creimer. You forgot to mention COBOL. Troll harder next time. This will get you started:
1) You're trolling me. 2) Did I forget to mention that the backend ran COBOL? No wonder you're hot and bothered. :P
Re: (Score:2)
Except this time it's important to catch the knowledge before it literally dies off.
Re: (Score:2)
Well, true, either that OR, slightly more plausible - some new hot-shot CIO decided he wants to impress the board by upping the ROI/stock price by getting rid of a few hundred (or thousand) old, slow, smelly "programmers". So he did.
Just like HSBC did in 2012, lest we forget. New hot-shot CIO decided..and a new hot-shot l337 h4xx0r from the indian subcontinent decided... to upgrade MQ, of all things. Clearing the "Queue" in MQ makes the upgrade quicker... How many million people couldn't get to their "banki
Re: (Score:2)