The largest bank in Sweden offers a free 16 week COBOL course once or twice a year. Basically anybody that passes is virtually guaranteed a job there.
Shortage of COBOL developers in insurance and banks
31–40 of 72 posts
Re: Shortage of COBOL developers in insurance and banks
#32There is a network of local state owned savings banks in Germany called Sparkasse. They have an in-house IT company called Finanz Informatik. I was surprised to learn that they actually had IT/Software Dev apprenticeships that taught COBOL and mainframes as their main subject. Apparently the program was somewhat successful for them.
When I've seen this in other banks it's been difficult to keep the junior devs interested in staying with COBOL. In general they wanted to move to other teams.
I don't blame them, some places would rather maintain their 1960s status quo than port to modern languages. It makes no sense but management is rather resistant to change.
Re: Shortage of COBOL developers in insurance and banks
#33The idea that COBOL is at the heart of bank systems is a persistent myth that gets published every now and again alongside some story about how essential these systems are, how they can never be replaced and how the people maintaining these systems are a dieing breed. Almost all of this seems untrue (except maybe the last one). I’ve worked at a variety of banks from front to back office across securities and private…
I've never worked in a bank. But I've been a sysadmin for a number of payroll and finances systems and some have run on COBOL. In particular a lot of PeopleSoft has key processes in COBOL. This is absolutely not obvious to anybody who is not actively working on that COBOL. Front end is a nice web Gui served by WebSphere or Weblogic. Rest of the system is enterprise Java. There's Python and RPA and all sort of fun stuff on the periphery, and obscure proprietary languages such as PeopleCode and ApplicationEngine (no not that one :) and God help me sqr. But core business logic that nobody touches directly except when they must is COBOL. Oracle still spits out PeopleSoft stuff in COBOL, used by thousands of companies (they're not actively selling PeopleSoft anymore, focusing on HCM cloud etc, but that too still happens)
Note, fwiw, while I personally happen to work for ibm, little to none of the COBOL I've encountered was running on ibm mainframes or even on ibm COBOL compiler. Most of it was third party software running on microfocus COBOL compiler... On windows and *nix.
Obviously just an anecdote like yours, but COBOL is definitely out there and not just on ibm mainframes:)
Re: Shortage of COBOL developers in insurance and banks
#34The idea that COBOL is at the heart of bank systems is a persistent myth that gets published every now and again alongside some story about how essential these systems are, how they can never be replaced and how the people maintaining these systems are a dieing breed. Almost all of this seems untrue (except maybe the last one). I’ve worked at a variety of banks from front to back office across securities and private…
It also appears in ways that you don’t expect. PeopleSoft is COBOL and they have like 25k+ customers. As we write, Oracle is trying to sell more COBOL into the enterprise in 2023 :)
> PeopleSoft is COBOL
The majority of PeopleSoft isn't COBOL – it is written in PeopleCode, a language PeopleSoft invented themselves (like SAP's ABAP), and I believe some newer components use Java too.
The COBOL is mainly used for batch processing and offline reporting in some of the older modules, such as Payroll. Many of the newer modules don't use any COBOL at all.
Re: Shortage of COBOL developers in insurance and banks
#35Earlier quoted context omitted.
It also appears in ways that you don’t expect. PeopleSoft is COBOL and they have like 25k+ customers. As we write, Oracle is trying to sell more COBOL into the enterprise in 2023 :)
> PeopleSoft is COBOL The majority of PeopleSoft isn't COBOL – it is written in PeopleCode, a language PeopleSoft invented themselves (like SAP's ABAP), and I believe some newer components use Java too. The COBOL is mainly used for batch processing and offline reporting in some of the older modules, such as Payroll. Many of the newer modules don't use any COBOL at all.
Right. Front is people code. Batch and heavy processing may be application engine or sqr, or COBOL. PeopleSoft HCM is their biggest product I think, and a lot of core (or old, if you prefer :) processes are in COBOL. Still getting updated, still actively used to pay many many millions of people in North America.
Re: Shortage of COBOL developers in insurance and banks
#36Earlier quoted context omitted.
When I've seen this in other banks it's been difficult to keep the junior devs interested in staying with COBOL. In general they wanted to move to other teams.
I don't blame them, some places would rather maintain their 1960s status quo than port to modern languages. It makes no sense but management is rather resistant to change.
Oh that's not the case here, management would love to get off these systems. They see the risks with the age profile of developers, staffing issues, and general ageing tech problems.
Re-writing these systems in another language is almost not an option. They have been written over decades with countless undocumented projects. They are core systems that work the way the business wants (or is built around, for better or worse), and doing a port would take years 100s of millions budgets and have a very high risk of failure.
I've seem smaller/non-core mainframe systems ported and they have been years delayed and plagued with issues, where it is very difficult to specify what is wanted other than something that is the same as the systems that is currently there with all it's weird corner cases.
Re: Shortage of COBOL developers in insurance and banks
#37As many said before ; it’s not learning Cobol (or Fortran), it’s the weird IBM mainframe/OS ecosystem that is the problem. I am good at both languages, but I know very little about the ecosystem it runs in.
As a Millennial, I haven't ever seen/touched/used a mainframe. And I work in a modern Data Center. What are the pros/cons of mainframe? What makes them better than a rack housed with necessary hardware? Well, I can see cons - not so accessible as regular hardware. Impractical/impossible to have at house. So the learning curve for hobbyists/tinkerers/curious are missing first steps.
Mainframes are great for large batch like tasks. They have very good security and the VM isolation is excellent. The hardware is very robust and uptimes can be very high.
With the large increases in computing power and storage available via AMD/Intel/Apple, the case is less compelling now.
Re: Shortage of COBOL developers in insurance and banks
#38The largest bank in Sweden offers a free 16 week COBOL course once or twice a year. Basically anybody that passes is virtually guaranteed a job there.
Wait, really? I briefly looked at Cobol job ads in Sweden (just for fun to see what's out there -- not actually looking for a Cobol job right now) recently and they were all looking for people with multiple years of production Cobol maintenance. I must have missed something obvious.
Re: Shortage of COBOL developers in insurance and banks
#39Earlier quoted context omitted.
I don't blame them, some places would rather maintain their 1960s status quo than port to modern languages. It makes no sense but management is rather resistant to change.
Oh that's not the case here, management would love to get off these systems. They see the risks with the age profile of developers, staffing issues, and general ageing tech problems. Re-writing these systems in another language is almost not an option. They have been written over decades with countless undocumented projects. They are core systems that work the way the business wants (or is built around, for better or…
Gotta rip the bandaid somehow. Even if it's not perfect, at least it would be more maintainable than COBOL.
Re: Shortage of COBOL developers in insurance and banks
#40The idea that COBOL is at the heart of bank systems is a persistent myth that gets published every now and again alongside some story about how essential these systems are, how they can never be replaced and how the people maintaining these systems are a dieing breed. Almost all of this seems untrue (except maybe the last one). I’ve worked at a variety of banks from front to back office across securities and private…
> Almost all of this seems untrue (except maybe the last one). I’ve worked at a variety of banks from front to back office across securities and private wealth. I’ve seen plenty of company-specific languages, plenty of C++, Java, perl, python but have literally never encountered a COBOL system. Two of Australia's four biggest banks – ANZ and Westpac – have historically run CSC Hogan. I don't know what they are doing…
They did good by not switching to the Oracle Banking Platform, after all, it's Oracle.