16 ms·

COBOL – Still standing the test of time

66 points by isaacfrond 5y ago

markus_zhang 5y ago
Gonna take up IBM mainframe courses this year to see if I can learn more about mainframes. This architecture ia completely different from PCs and it's nice to learn new types of low level programming.
- 656565656565 5y ago
  Master the Mainframe usually is around this time of the year, recommend it.
  - markus_zhang 5y ago
    Yeah exactly. I read sometime before they changed the name but the content sholdd be the same.
- pjmlp 5y ago
  IBM and Unisys have their manuals online. IBM Redbooks are quite good.
  - markus_zhang 5y ago
    Yeah I saw a full set of redbook manuals regarding low level sys prog and amazed by its quality.
656565656565 5y ago
Article is 2012. Edit: please add (2012) to the title.
bluejekyll 5y ago
I've always thought that the reason COBOL is still "popular" is that it became an entrenched technology many years ago, and the cost of replacement is high enough (and it works fine doing what it's doing) that no one wants to invest the time and money to replace it's usage. This quote made me pause though, "COBOL remains the preferred choice for systems where application quality and operating cost remain important considerations". How much is COBOL being "chosen" vs. COBOL is basically required b/c of the existing codebase and systems that need to be integrated with? The latter is my guess, and the choice seems to be really, "what's the best way to extend this existing system?" If that system is in Java, it's probably Java... C it's probably C... COBOL it's probably COBOL.
- haswell 5y ago
  I spent ~7 years or so at one of the large credit card companies. The adage "if it isn't broke, don't fix it" was very prevalent there, and anything that even hinted at touching the core payment processing code was scrutinized heavily and usually avoided entirely. At the time, the cost of an outage was estimated in the $100K's per minute, and is likely significantly higher now. When I moved away from FinServ, I found it surprising at first how cavalier some orgs are about ripping/replacing core services in the name of "modernization". Move fast & break things and all of that...
  - loganfrederick 5y ago
    As someone who was recruited to a financial firm a year ago to execute a modernization effort, I think the difference is due to (simplified) two types of firms: Big ones with huge moats often protected by regulators and profitability, and ones that are insecure. There is a pretty big population of companies that are at huge risk of being disrupted in the best sense of that term, and that's why they need to modernize. Many of these outdated core systems don't have modern capabilities, such as being desktop apps that can't integrate with the web or provide/use APIs without heavy refactoring anyway.
    - bluGill 5y ago
      Those big companies can be disrupted even faster if they break something though. I'm not allowed to talk about it, but I know people in tier-2 support who were on an all night phone call with a big bank customer because if the computer wasn't up by morning the government would shut them down. (somewhat like the government did shut down some big banks in the 2008 crisis, but this was in the 1990s) At the start of the call the rep told them "We are pretty sure we know where the problem is and it isn't you, but we need you on the phone anyway just in case anyone has a question you are ready to answer." That is also why big companies have the million dollar support contracts: someone who can stay up all night and answer obscure questions. Break things is a bad thing sometimes. I wish more of the move fast and break things companies would realize who annoying it is when they break something.
  - 5y ago
oneplane 5y ago
It's funny how it's presented as "standing the test of time". There is plenty of "old stuff" that still exists and those aren't tested by time either, it's just that there is not enough of an incentive or foresight to do something about it. If general OOP-language software engineers had the same army of QA, PR, marketing and sales people that mainframes have you'd probably end up with the same thing. I'd say COBOLs continued existence isn't the main case, it's just a side-effect.
ltbarcly3 5y ago
>> While many also debate the status of Java in relation to COBOL for business applications, COBOL remains the preferred choice for systems where application quality and operating cost remain important considerations, so often the case when addressing the ever-present issue of IT debt. When many businesses are facing mounting IT debt, the average cost per line of code for COBOL was projected to be £0.80 whereas the cost to address Java quality issues per line of code was £3.47, according to a recent IT study. "That oil in the fryer at your local bowling alley that has gone rancid but they refuse to change it because the guy who knew how to drain the old oil quit - still standing the test of time" While many also debate the status of new oil in relation to rancid oil for french fries, rancid oil remains the preferred choice for deep fryers where knowing how to change the oil and cost remain important considerations, so often the case when addressing the ever-present issue of stuff only Bill knew how to do. When many bowling alleys are facing mounting problems due to not making sure someone else could drain the oil besides 'their Bill', the average cost per gallon of oil for rancid oil already in the fryer was projected to be £0.00 whereas the cost to go to Costco and get 15 gallons of new oil was £8.73, according to Chelsea who is at Costco like every day.
wsh 5y ago
Micro Focus is one of the main suppliers of COBOL compilers, so it’s not surprising that they would argue that the language is still relevant.
mhh__ 5y ago
Has anyone ever actually met a COBOL programmer? It seems like the teachers tale of someone cracking their head open while swinging on their chair - presumably they exist but there can't be that many of them?
- splistud 5y ago
  More than a hundred, probably less than 500
- pjdemers 5y ago
  I used to do consulting in banks. I met several Cobol programmers. However, they thought of their role as CICS programmers. CICS is a mainframe transaction management tool. All of them also did assembly in CICS.
- philipswood 5y ago
  I met some Cobol programmers in an open office space at a bank. Pleasant, relaxed bunch.
- Kaytaro 5y ago
  My job involves a lot of projects with IBM i and Z so I meet a lot of them. It's pretty much the "greybeards" you'd expect, but also surprisingly there's a LOT of older women in these roles. Like, proportionally way more than an in open systems world in my experience. I've always wondered why that is, I have heard that programming used to be considered a "woman's job" so maybe that's it.
  - throwawayboise 5y ago
    I worked at an investment bank in the 1990s. Their programming staff (and IT staff in general) was roughly half female. I think it's more common in companies where IT is a supporting function and not the core business. By contrast, the tech companies I've worked at have all been almost entirely male.
  - jcranmer 5y ago
    From what I've been told, CS was a pretty balanced industry in terms of gender until the dot-com bubble, where it became very heavily male-skewed and hasn't recovered since.
DonHopkins 5y ago
COBOL Forever! https://donhopkins.medium.com/cobol-forever-1a49f7d28a39 https://donhopkins.medium.com/cobol-forever-1a49f7d28a39
forinti 5y ago
The thing about the "average line of code" is that a line of COBOL rarely does much. You can do a lot more with a line of Java and, of course, with a line of Perl or Python you can do very complex things.
- mjcohen 5y ago
  Try a MOVE CORRESPONDING.
habibur 5y ago
This article is from 2012, 9 years old. Thing might have changed a lot after that.
- dboreham 5y ago
  Probably not. New systems got built around the big iron is what happened.
zelphirkalt 5y ago
If a system is not really changed a lot, if the attitude is to keep what is currently working and avoid risk of anything breaking through change, then I ask: What is that "test of time"? What is it, that needs to be stood here? If nothing new is introduced to the system, then most likely it would still work in thousands of years. That is no achievement in itself. All deterministic software does this.
- IncRnd 5y ago
  > All deterministic software does this. That stands to reason, yet much software is decomissioned or replaced every year. All of it deterministic software. Perhaps the software is expensive to maintain or use, doesn't adequately meet the needs of the business, is error-prone, or any one of a million reasons. COBOL works at the heart of our industry and our society, despite COBOL being an ancient crufty language. In the same way that may of us never see our hearts or become heart surgeons, I may never meet a COBOL program or a COBOL programmer. I am still thankful they are there, and I recognize they serve a function other software likely would not.
theshetty 5y ago
I started my career with a first job in 2009 (not long time ago!) as a COBOL/JCL programmer (and went on to do TELON programming later) for one of the biggest retailer in the country. The systems that managed the forecasting for replenishable and non-replinshable products, markdowns (i.e., discounts) on products in the stores, stock warehouse etc. across the country was completely built on COBOL/JCL+DB2 stack combined with TELON online screens for business to manage the solution/system. This system practically worked round the clock with hardly any downtime, and in the peak season (like Christmas when the sales/transactions were at it's high) too worked without any major issues. I'm sure IBM still earns a big chunk of revenue from mainframes from these big customers. I remember an attempt was made to migrate some (if not all) to a new generation data analytics platform and it didn't go very well, so they just stuck with what they had. One of the main reason I can think of is the the cost of this migration was too high (vs. the realised benefit) as the system just worked for the business and was quite resilient. I since then jumped ship to the very technology they were trying to migrate too and have never looked back really. I think I can still work my way out of COBOL/JCL + TELON/CICS, perhaps I will forget them very soon :)
- phoehne 5y ago
  I was part of a team that wrote a paper for a customer on replacing 5 million lines of legacy COBOL code with either hand-written or machine-generated Java for a major system. The cost was in the mid 9 figures.
jimt1234 5y ago
My mother spent much of her career as a COBOL programmer, dating back to the early 80s. She retired in 2015 and quickly got bored. I talked her into accepting part-time contract work, something to keep her busy. She got flooded by recruiters. They all told her the same story: "Big Corp" is nervous because a critical system runs COBOL and the staff that used to support it have all either retired or died. She decided against taking any contract work, telling me that once she retired, a switch flipped in her head - she could never go back to work, not for all the money in the world. Good for you, mom.
- markus_zhang 5y ago
  I wonder why those big companies don't hire someone new and train them. I'm sure not everyone is interested in new techs. I for one is very interested in these "boring" techs but it's pretty difficult to train myself on these stuffs.
  - Zababa 5y ago
    They don't pay enough. That's the issue. If COBOL paid as much or better for the average developer than Java, there would be no shortage of COBOL developers.
    - markus_zhang 5y ago
      Good point. Maybe new developer salary is different from what contractors get? The number I see for contractors are pretty good but yeah they have decades of experience under their belt.
    - jimt1234 5y ago
      The contract offers my mother received involved good money, but that was actually part of the problem. She got the impression that most of the managers at "Big Corp" had little/no regard for these "critical" systems; they were just looking to save their own jobs, either by way of a miracle worker (wave a magic wand and fix 40 years of tech debt in 3 months) or a fall guy (it's the contractor's fault, not mine). Also, COBOL work is kinda crap. Debugging 20-year-old Java code sucks, but a 40-year-old COBOL project, with source code backed up to 5-inch floppy disks - forget about it. (I just watched the trailer for 'The Many Saints of Newark'. LOL)
giantg2 5y ago
[announcer] Get ready to Rumba!!!
tegansnyder 5y ago
I went to community technical college in 2005 and the primary course load was COBOL and JAVA. The college was a pipeline to to bring fresh COBOL talent into these big financial institutions. I'm not sure how many colleges are doing this across the USA currently, but I'm sure there are a handful.
asien 5y ago
> Cobol remains the language of choice Sigh , those single liner that both illustrate the ignorance and the status of the author. I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation. My mission was very simple « move the bank the out of mainframe » In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time manner as opposed to « batch » processing while covering and simplifying 90% of banks related scenario ( SEPA , MasterCard , AML etc...) The project was accepted by directors but devs refused to go into that because much like the authors they are 30 years in the banks and don’t want to learn something else than what they know « cobol ». 90% of our contractors work is spent dealing with mainframe constraint and writing interfaces and top of that piece of crap that can only process data at night or during the weekend. Mainframe is not there because « it’s superior » , distributed system have largely proven their capability and maturity. Mainframe are still there because of Corporates Politics and lack of Leadership from top management. When you are reminded that Citibank lost 0.5 Billions because they spent 0$ on their UI, you may start to understand how much corporates world is rotten to its core and why mainframe is still there. Has nothing to do with it’s capability , period.
- simonblack 5y ago
  devs refused to go into that because much like the authors they are 30 years in the banks and don’t want to learn something else The way to fix that is to use the method IBM used to introduce the IBM-PC back in 1981. They set up a completely independent project group that had no connection with the main-frame boys, and so weren't 'brainwashed' into the IBM 'way of life'. The rest is history. Incidentally, while I no longer program in COBOL, I still like it. It was always easy to do maintenance on a program that I might not have looked at for decades because of its wordiness. I normally program in C these days, but it's not as 'maintenance-friendly' as COBOL unless there are lots of comments.
- ncr100 5y ago
  (humor) > COBOL- still standing the test of time .. like the plague. https://en.wikipedia.org/wiki/Bubonic_plague#History https://en.wikipedia.org/wiki/Bubonic_plague#History
- 5y ago
mjcohen 5y ago
I did a lot of COBOL in the U. S. Army in 1967-68. Wonder if I could get a reasonably paying job doing it now.
zoom6628 5y ago
I like the commenter on that page disagree with the stats but I would assert that COBOL is still the best business DSL ever written. the whole language is about doing typical business things. Mostevery other language I have used, looked at, is at the primitives level upon which one has to build the functions to make it equivalent to COBOL for writing a simple accounting program. Add to this it's IO is basically just the 2 fundamentals of record based read write and queues(yes COBOL had queues in 70s). if you have written large business systems with multiple data storage backend, and its distributed, and it needs to manage it's own load balancing, then COBOL was brilliant. Still is. world (and a lot of HN readers) needs to change mindset away from this lang versus that lang towards a this DSL and its problem space versus others DSL and its problem space. For me if I had to write a payroll engine I would prefer use COBOL than javascript but would likely turn to java just because of easier to get reference material. I learned fortran, Pascal, cobol. then worked in COBOL and assembler. then RPG and awk. nowadays mostly python, javascript, some c for projects. FWIW I aspire to learn and use Ada.
- lmm 5y ago
  Learning a dozen interchangeable ALGOL-family languages doesn't teach you much more than learning one or two. You'd get more out of learning an ML-like language, a Lisp, an array language, something like Prolog...
arnmac 5y ago
Of course this article on microfocus.com is going to talk about how great Cobol is. Microfocus is one of the major Cobol vendors. That said I had a professor that made lots of retirement money off his Cobol abilities. He laughed and said he made more money fixing his optimizations for Y2K then he did in all the years he was a full-time professional Cobol dev.
ibiza 5y ago
COBOL is extremely good at what it does. I know of no other language that even approaches it. * It has a data division which lets you describe nested, repeating, and overlapping data at the byte level with a clear, unambiguous notation. * Numbers are treated as decimal values (generally) and math is likewise done in decimal, not binary. * It is profoundly cross-platform. You can take a memory-map from one architecture, slam it to disk, transfer it to another machine with a different architecture, load it into memory, and have perfect fidelity. What other languages have these properties? Yes, it is clunky as hell. It is not good for many things. However, for its intended use, it is very good.
Lancemaria 5y ago
I was able to get my credit fixed by DOOMHACKS@BK.RU after a long search of a good reliable hacker to work with .. i had few negatives on my credit that deprived me of getting a new apartment and a car as well .. i had a low credit of 480 before i came across them , but after they were done my credit was back up to 800 .. The best i have ever came across and told me the very truth i needed to hear .. Text them and get the issues you got on your credit sorted out +1 812 509 3064
bobbydreamer 5y ago
Some common lines you hear from mainframers. Deprecation is a new term in mainframe. Don't fix what's not broken ------ It's a common saying that mainframers don't try to learn new tech. Well that saying goes two ways, person saying has really tried to learning mainframe and work on it for a month. Actually there isn't much to learn other than couple of languages COBOL, REXX, JCL and SAS. Other than that it's just ISPF interfaces. Mainframers actually have to learn tech once and then go on to learn business logics and business domain. Isnt that actually good when comparing to always learning new tech and writing migrating programs to support existing interface in new Lang but not too much about business you are working on. On the other hand mainframers do spend on learning and upskilling but in mainframe itself. There are lots of IBM Usergroups like IDUG for instance which is related to Db2, being a DBA that's a very useful training programme for me. COBOL codes are highly modularized to do one or couple of functions to my knowledge and there are definitely coding standards each shop maintains. Having a bunch of nodeJs cloud functions i get an email from Google saying that I need to migrate my NodeJs or it will stop functioning and while trying to migrate i find couple of modules are not longer supported and I need recode. Here I am not adding any new features just trying to make it work as before with new library which I have to find, learn, test and analyse does it suit then recode. All this costs time which you don't have to do in mainframe. You can say why not run in a VM, then what's the point running in cloud. Mainframe is not a legacy system. IBM introduces a new machine every 3-4 years and send their sales team to visit corps and run presentations :) . Currently IBM has changed their billing style, it's not flat or peak hour, it's custom. It's the smallest footprint in your data center. What mainframe actually did is, job separation. So in a career a person will sort of become an expert in their line or software. He will know all the ins and outs. For example a RACF security person will not know about Db2 and how it functions only part he knows is what interfaces with RACF. Same with CICS, MQ.... From application/dev team they get to know business like in a requirement meeting when business talks devs will be mapping business with program modules they had to make a change. In mainframe people get to specialize.

66 points by isaacfrond 5y ago

Gonna take up IBM mainframe courses this year to see if I can learn more about mainframes. This architecture ia completely different from PCs and it's nice to learn new types of low level programming.

656565656565 5y ago
Master the Mainframe usually is around this time of the year, recommend it.
- markus_zhang 5y ago
  Yeah exactly. I read sometime before they changed the name but the content sholdd be the same.
pjmlp 5y ago
IBM and Unisys have their manuals online. IBM Redbooks are quite good.
- markus_zhang 5y ago
  Yeah I saw a full set of redbook manuals regarding low level sys prog and amazed by its quality.

656565656565 5y ago

Article is 2012. Edit: please add (2012) to the title.

bluejekyll 5y ago

I've always thought that the reason COBOL is still "popular" is that it became an entrenched technology many years ago, and the cost of replacement is high enough (and it works fine doing what it's doing) that no one wants to invest the time and money to replace it's usage. This quote made me pause though, "COBOL remains the preferred choice for systems where application quality and operating cost remain important considerations". How much is COBOL being "chosen" vs. COBOL is basically required b/c of the existing codebase and systems that need to be integrated with? The latter is my guess, and the choice seems to be really, "what's the best way to extend this existing system?" If that system is in Java, it's probably Java... C it's probably C... COBOL it's probably COBOL.

haswell 5y ago
I spent ~7 years or so at one of the large credit card companies. The adage "if it isn't broke, don't fix it" was very prevalent there, and anything that even hinted at touching the core payment processing code was scrutinized heavily and usually avoided entirely. At the time, the cost of an outage was estimated in the $100K's per minute, and is likely significantly higher now. When I moved away from FinServ, I found it surprising at first how cavalier some orgs are about ripping/replacing core services in the name of "modernization". Move fast & break things and all of that...
- loganfrederick 5y ago
  As someone who was recruited to a financial firm a year ago to execute a modernization effort, I think the difference is due to (simplified) two types of firms: Big ones with huge moats often protected by regulators and profitability, and ones that are insecure. There is a pretty big population of companies that are at huge risk of being disrupted in the best sense of that term, and that's why they need to modernize. Many of these outdated core systems don't have modern capabilities, such as being desktop apps that can't integrate with the web or provide/use APIs without heavy refactoring anyway.
  - bluGill 5y ago
    Those big companies can be disrupted even faster if they break something though. I'm not allowed to talk about it, but I know people in tier-2 support who were on an all night phone call with a big bank customer because if the computer wasn't up by morning the government would shut them down. (somewhat like the government did shut down some big banks in the 2008 crisis, but this was in the 1990s) At the start of the call the rep told them "We are pretty sure we know where the problem is and it isn't you, but we need you on the phone anyway just in case anyone has a question you are ready to answer." That is also why big companies have the million dollar support contracts: someone who can stay up all night and answer obscure questions. Break things is a bad thing sometimes. I wish more of the move fast and break things companies would realize who annoying it is when they break something.
- 5y ago

oneplane 5y ago

It's funny how it's presented as "standing the test of time". There is plenty of "old stuff" that still exists and those aren't tested by time either, it's just that there is not enough of an incentive or foresight to do something about it. If general OOP-language software engineers had the same army of QA, PR, marketing and sales people that mainframes have you'd probably end up with the same thing. I'd say COBOLs continued existence isn't the main case, it's just a side-effect.

ltbarcly3 5y ago

>> While many also debate the status of Java in relation to COBOL for business applications, COBOL remains the preferred choice for systems where application quality and operating cost remain important considerations, so often the case when addressing the ever-present issue of IT debt. When many businesses are facing mounting IT debt, the average cost per line of code for COBOL was projected to be £0.80 whereas the cost to address Java quality issues per line of code was £3.47, according to a recent IT study. "That oil in the fryer at your local bowling alley that has gone rancid but they refuse to change it because the guy who knew how to drain the old oil quit - still standing the test of time" While many also debate the status of new oil in relation to rancid oil for french fries, rancid oil remains the preferred choice for deep fryers where knowing how to change the oil and cost remain important considerations, so often the case when addressing the ever-present issue of stuff only Bill knew how to do. When many bowling alleys are facing mounting problems due to not making sure someone else could drain the oil besides 'their Bill', the average cost per gallon of oil for rancid oil already in the fryer was projected to be £0.00 whereas the cost to go to Costco and get 15 gallons of new oil was £8.73, according to Chelsea who is at Costco like every day.

wsh 5y ago

Micro Focus is one of the main suppliers of COBOL compilers, so it’s not surprising that they would argue that the language is still relevant.

mhh__ 5y ago

Has anyone ever actually met a COBOL programmer? It seems like the teachers tale of someone cracking their head open while swinging on their chair - presumably they exist but there can't be that many of them?

splistud 5y ago
More than a hundred, probably less than 500
pjdemers 5y ago
I used to do consulting in banks. I met several Cobol programmers. However, they thought of their role as CICS programmers. CICS is a mainframe transaction management tool. All of them also did assembly in CICS.
philipswood 5y ago
I met some Cobol programmers in an open office space at a bank. Pleasant, relaxed bunch.
Kaytaro 5y ago
My job involves a lot of projects with IBM i and Z so I meet a lot of them. It's pretty much the "greybeards" you'd expect, but also surprisingly there's a LOT of older women in these roles. Like, proportionally way more than an in open systems world in my experience. I've always wondered why that is, I have heard that programming used to be considered a "woman's job" so maybe that's it.
- throwawayboise 5y ago
  I worked at an investment bank in the 1990s. Their programming staff (and IT staff in general) was roughly half female. I think it's more common in companies where IT is a supporting function and not the core business. By contrast, the tech companies I've worked at have all been almost entirely male.
- jcranmer 5y ago
  From what I've been told, CS was a pretty balanced industry in terms of gender until the dot-com bubble, where it became very heavily male-skewed and hasn't recovered since.

DonHopkins 5y ago

COBOL Forever! https://donhopkins.medium.com/cobol-forever-1a49f7d28a39 https://donhopkins.medium.com/cobol-forever-1a49f7d28a39

forinti 5y ago

The thing about the "average line of code" is that a line of COBOL rarely does much. You can do a lot more with a line of Java and, of course, with a line of Perl or Python you can do very complex things.

mjcohen 5y ago
Try a MOVE CORRESPONDING.

habibur 5y ago

This article is from 2012, 9 years old. Thing might have changed a lot after that.

dboreham 5y ago
Probably not. New systems got built around the big iron is what happened.

zelphirkalt 5y ago

If a system is not really changed a lot, if the attitude is to keep what is currently working and avoid risk of anything breaking through change, then I ask: What is that "test of time"? What is it, that needs to be stood here? If nothing new is introduced to the system, then most likely it would still work in thousands of years. That is no achievement in itself. All deterministic software does this.

IncRnd 5y ago
> All deterministic software does this. That stands to reason, yet much software is decomissioned or replaced every year. All of it deterministic software. Perhaps the software is expensive to maintain or use, doesn't adequately meet the needs of the business, is error-prone, or any one of a million reasons. COBOL works at the heart of our industry and our society, despite COBOL being an ancient crufty language. In the same way that may of us never see our hearts or become heart surgeons, I may never meet a COBOL program or a COBOL programmer. I am still thankful they are there, and I recognize they serve a function other software likely would not.

theshetty 5y ago

I started my career with a first job in 2009 (not long time ago!) as a COBOL/JCL programmer (and went on to do TELON programming later) for one of the biggest retailer in the country. The systems that managed the forecasting for replenishable and non-replinshable products, markdowns (i.e., discounts) on products in the stores, stock warehouse etc. across the country was completely built on COBOL/JCL+DB2 stack combined with TELON online screens for business to manage the solution/system. This system practically worked round the clock with hardly any downtime, and in the peak season (like Christmas when the sales/transactions were at it's high) too worked without any major issues. I'm sure IBM still earns a big chunk of revenue from mainframes from these big customers. I remember an attempt was made to migrate some (if not all) to a new generation data analytics platform and it didn't go very well, so they just stuck with what they had. One of the main reason I can think of is the the cost of this migration was too high (vs. the realised benefit) as the system just worked for the business and was quite resilient. I since then jumped ship to the very technology they were trying to migrate too and have never looked back really. I think I can still work my way out of COBOL/JCL + TELON/CICS, perhaps I will forget them very soon :)

phoehne 5y ago
I was part of a team that wrote a paper for a customer on replacing 5 million lines of legacy COBOL code with either hand-written or machine-generated Java for a major system. The cost was in the mid 9 figures.

jimt1234 5y ago

My mother spent much of her career as a COBOL programmer, dating back to the early 80s. She retired in 2015 and quickly got bored. I talked her into accepting part-time contract work, something to keep her busy. She got flooded by recruiters. They all told her the same story: "Big Corp" is nervous because a critical system runs COBOL and the staff that used to support it have all either retired or died. She decided against taking any contract work, telling me that once she retired, a switch flipped in her head - she could never go back to work, not for all the money in the world. Good for you, mom.

markus_zhang 5y ago
I wonder why those big companies don't hire someone new and train them. I'm sure not everyone is interested in new techs. I for one is very interested in these "boring" techs but it's pretty difficult to train myself on these stuffs.
- Zababa 5y ago
  They don't pay enough. That's the issue. If COBOL paid as much or better for the average developer than Java, there would be no shortage of COBOL developers.
  - markus_zhang 5y ago
    Good point. Maybe new developer salary is different from what contractors get? The number I see for contractors are pretty good but yeah they have decades of experience under their belt.
  - jimt1234 5y ago
    The contract offers my mother received involved good money, but that was actually part of the problem. She got the impression that most of the managers at "Big Corp" had little/no regard for these "critical" systems; they were just looking to save their own jobs, either by way of a miracle worker (wave a magic wand and fix 40 years of tech debt in 3 months) or a fall guy (it's the contractor's fault, not mine). Also, COBOL work is kinda crap. Debugging 20-year-old Java code sucks, but a 40-year-old COBOL project, with source code backed up to 5-inch floppy disks - forget about it. (I just watched the trailer for 'The Many Saints of Newark'. LOL)

giantg2 5y ago

[announcer] Get ready to Rumba!!!

tegansnyder 5y ago

I went to community technical college in 2005 and the primary course load was COBOL and JAVA. The college was a pipeline to to bring fresh COBOL talent into these big financial institutions. I'm not sure how many colleges are doing this across the USA currently, but I'm sure there are a handful.

asien 5y ago

> Cobol remains the language of choice Sigh , those single liner that both illustrate the ignorance and the status of the author. I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation. My mission was very simple « move the bank the out of mainframe » In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time manner as opposed to « batch » processing while covering and simplifying 90% of banks related scenario ( SEPA , MasterCard , AML etc...) The project was accepted by directors but devs refused to go into that because much like the authors they are 30 years in the banks and don’t want to learn something else than what they know « cobol ». 90% of our contractors work is spent dealing with mainframe constraint and writing interfaces and top of that piece of crap that can only process data at night or during the weekend. Mainframe is not there because « it’s superior » , distributed system have largely proven their capability and maturity. Mainframe are still there because of Corporates Politics and lack of Leadership from top management. When you are reminded that Citibank lost 0.5 Billions because they spent 0$ on their UI, you may start to understand how much corporates world is rotten to its core and why mainframe is still there. Has nothing to do with it’s capability , period.

simonblack 5y ago
devs refused to go into that because much like the authors they are 30 years in the banks and don’t want to learn something else The way to fix that is to use the method IBM used to introduce the IBM-PC back in 1981. They set up a completely independent project group that had no connection with the main-frame boys, and so weren't 'brainwashed' into the IBM 'way of life'. The rest is history. Incidentally, while I no longer program in COBOL, I still like it. It was always easy to do maintenance on a program that I might not have looked at for decades because of its wordiness. I normally program in C these days, but it's not as 'maintenance-friendly' as COBOL unless there are lots of comments.
ncr100 5y ago
(humor) > COBOL- still standing the test of time .. like the plague. https://en.wikipedia.org/wiki/Bubonic_plague#History https://en.wikipedia.org/wiki/Bubonic_plague#History
5y ago

mjcohen 5y ago

I did a lot of COBOL in the U. S. Army in 1967-68. Wonder if I could get a reasonably paying job doing it now.

zoom6628 5y ago

I like the commenter on that page disagree with the stats but I would assert that COBOL is still the best business DSL ever written. the whole language is about doing typical business things. Mostevery other language I have used, looked at, is at the primitives level upon which one has to build the functions to make it equivalent to COBOL for writing a simple accounting program. Add to this it's IO is basically just the 2 fundamentals of record based read write and queues(yes COBOL had queues in 70s). if you have written large business systems with multiple data storage backend, and its distributed, and it needs to manage it's own load balancing, then COBOL was brilliant. Still is. world (and a lot of HN readers) needs to change mindset away from this lang versus that lang towards a this DSL and its problem space versus others DSL and its problem space. For me if I had to write a payroll engine I would prefer use COBOL than javascript but would likely turn to java just because of easier to get reference material. I learned fortran, Pascal, cobol. then worked in COBOL and assembler. then RPG and awk. nowadays mostly python, javascript, some c for projects. FWIW I aspire to learn and use Ada.

lmm 5y ago
Learning a dozen interchangeable ALGOL-family languages doesn't teach you much more than learning one or two. You'd get more out of learning an ML-like language, a Lisp, an array language, something like Prolog...

arnmac 5y ago

Of course this article on microfocus.com is going to talk about how great Cobol is. Microfocus is one of the major Cobol vendors. That said I had a professor that made lots of retirement money off his Cobol abilities. He laughed and said he made more money fixing his optimizations for Y2K then he did in all the years he was a full-time professional Cobol dev.

ibiza 5y ago

COBOL is extremely good at what it does. I know of no other language that even approaches it. * It has a data division which lets you describe nested, repeating, and overlapping data at the byte level with a clear, unambiguous notation. * Numbers are treated as decimal values (generally) and math is likewise done in decimal, not binary. * It is profoundly cross-platform. You can take a memory-map from one architecture, slam it to disk, transfer it to another machine with a different architecture, load it into memory, and have perfect fidelity. What other languages have these properties? Yes, it is clunky as hell. It is not good for many things. However, for its intended use, it is very good.

Lancemaria 5y ago

I was able to get my credit fixed by DOOMHACKS@BK.RU after a long search of a good reliable hacker to work with .. i had few negatives on my credit that deprived me of getting a new apartment and a car as well .. i had a low credit of 480 before i came across them , but after they were done my credit was back up to 800 .. The best i have ever came across and told me the very truth i needed to hear .. Text them and get the issues you got on your credit sorted out +1 812 509 3064

bobbydreamer 5y ago

Some common lines you hear from mainframers. Deprecation is a new term in mainframe. Don't fix what's not broken ------ It's a common saying that mainframers don't try to learn new tech. Well that saying goes two ways, person saying has really tried to learning mainframe and work on it for a month. Actually there isn't much to learn other than couple of languages COBOL, REXX, JCL and SAS. Other than that it's just ISPF interfaces. Mainframers actually have to learn tech once and then go on to learn business logics and business domain. Isnt that actually good when comparing to always learning new tech and writing migrating programs to support existing interface in new Lang but not too much about business you are working on. On the other hand mainframers do spend on learning and upskilling but in mainframe itself. There are lots of IBM Usergroups like IDUG for instance which is related to Db2, being a DBA that's a very useful training programme for me. COBOL codes are highly modularized to do one or couple of functions to my knowledge and there are definitely coding standards each shop maintains. Having a bunch of nodeJs cloud functions i get an email from Google saying that I need to migrate my NodeJs or it will stop functioning and while trying to migrate i find couple of modules are not longer supported and I need recode. Here I am not adding any new features just trying to make it work as before with new library which I have to find, learn, test and analyse does it suit then recode. All this costs time which you don't have to do in mainframe. You can say why not run in a VM, then what's the point running in cloud. Mainframe is not a legacy system. IBM introduces a new machine every 3-4 years and send their sales team to visit corps and run presentations :) . Currently IBM has changed their billing style, it's not flat or peak hour, it's custom. It's the smallest footprint in your data center. What mainframe actually did is, job separation. So in a career a person will sort of become an expert in their line or software. He will know all the ins and outs. For example a RACF security person will not know about Db2 and how it functions only part he knows is what interfaces with RACF. Same with CICS, MQ.... From application/dev team they get to know business like in a requirement meeting when business talks devs will be mapping business with program modules they had to make a change. In mainframe people get to specialize.