3 ms·

All things related to mainframe, cics, cobol etc. It seems like it has been tried to replace it for decades. But it also seems like that replacement is not gett

All things related to mainframe, cics, cobol etc. It seems like it has been tried to replace it for decades. But it also seems like that replacement is not getting anywhere.

cpitman 4y ago
This is the most real answer so far. Knowledge is being lost in the field, very few want to learn the field, and it is needed in just about every company. Companies that existed in the 80s and have managed to migrate off of the mainframe are the very very small minority. Pay is part of this, but I'd posit that most programmers would need to be paid a hefty premium over standard rates to be will to work on what they consider legacy or dying technology.
- gaoshancha 4y ago
  I found this to be an area that really doesn’t want motivated people, just entry level blank slate newcomers. I tried to get into this field for four years and gave up. I’ve got 10+ years as a UNIX guy mind you. I participated in IBM master the mainframe every year to get real hands-on experience and practice. I did IBMs courses on Coursera for more practice. I read the red books to learn even more! I also took classes at an community college on IBM midranges too as a potential alternative to mainframes; I interned at a factory and worked with RPG-IV and AS/400 way back. Yet I didn’t get a single reply to a resume I sent out, not even a follow up email. If you really look into this, IBM and their network of partner companies that do mainframes are really only looking for entry level folks out of college or 2 year schools. My guess is that companies have slashed their mainframe budgets so much they can’t afford non-entry level folks, and assumed experienced techs won’t take the pay cuts. It won’t be until the mass retirements that organizations will really panic I suppose… It was at least fun learning the tech though, would love to had the opportunity to learn even more. Or even just have access to a system z to continue learning on…
thedougd 4y ago
I directly worked on the planning of a replacement deposits system for a major financial institution. The existing system was written in COBOL and the vendor did not want to continue any business, including maintenance support, on this old software. We were already able to extend the software ourselves without their help to add integrations or features. Consultants came in and offered the following suggestions: 1) Write new software to replace. Estimate $3-400 million dollars. 2) Use a product that would transpile the COBOL to Java. We chose option 3: offer a lump sump to license the software in perpetuity and maintain ourselves. Built a layer around it to better enable the systems of engagement use cases. The problem with #1 and #2 is documenting all the use cases and validating them after changes are made. Can you even imagine the resulting Java code for #2? There are many edge case behaviors that were either purposeful or accidental, but now relied upon by downstream software. To summarize, there's a huge price tag to replace these systems, it's an extremely high risk exercise, and the benefits to the business are at best incremental. It's easy to see why the financial sector won't bother until either regulators force them or they acquire another institution with a better system.

All things related to mainframe, cics, cobol etc. It seems like it has been tried to replace it for decades. But it also seems like that replacement is not getting anywhere.

cpitman 4y ago

This is the most real answer so far. Knowledge is being lost in the field, very few want to learn the field, and it is needed in just about every company. Companies that existed in the 80s and have managed to migrate off of the mainframe are the very very small minority. Pay is part of this, but I'd posit that most programmers would need to be paid a hefty premium over standard rates to be will to work on what they consider legacy or dying technology.

gaoshancha 4y ago
I found this to be an area that really doesn’t want motivated people, just entry level blank slate newcomers. I tried to get into this field for four years and gave up. I’ve got 10+ years as a UNIX guy mind you. I participated in IBM master the mainframe every year to get real hands-on experience and practice. I did IBMs courses on Coursera for more practice. I read the red books to learn even more! I also took classes at an community college on IBM midranges too as a potential alternative to mainframes; I interned at a factory and worked with RPG-IV and AS/400 way back. Yet I didn’t get a single reply to a resume I sent out, not even a follow up email. If you really look into this, IBM and their network of partner companies that do mainframes are really only looking for entry level folks out of college or 2 year schools. My guess is that companies have slashed their mainframe budgets so much they can’t afford non-entry level folks, and assumed experienced techs won’t take the pay cuts. It won’t be until the mass retirements that organizations will really panic I suppose… It was at least fun learning the tech though, would love to had the opportunity to learn even more. Or even just have access to a system z to continue learning on…

thedougd 4y ago

I directly worked on the planning of a replacement deposits system for a major financial institution. The existing system was written in COBOL and the vendor did not want to continue any business, including maintenance support, on this old software. We were already able to extend the software ourselves without their help to add integrations or features. Consultants came in and offered the following suggestions: 1) Write new software to replace. Estimate $3-400 million dollars. 2) Use a product that would transpile the COBOL to Java. We chose option 3: offer a lump sump to license the software in perpetuity and maintain ourselves. Built a layer around it to better enable the systems of engagement use cases. The problem with #1 and #2 is documenting all the use cases and validating them after changes are made. Can you even imagine the resulting Java code for #2? There are many edge case behaviors that were either purposeful or accidental, but now relied upon by downstream software. To summarize, there's a huge price tag to replace these systems, it's an extremely high risk exercise, and the benefits to the business are at best incremental. It's easy to see why the financial sector won't bother until either regulators force them or they acquire another institution with a better system.