Interesting personal perspective, thanks for posting!
It sounds like other than the very slow database, the biggest impediment in this space is the lack of new talent familiar with the environment.
It sounds like other than the very slow database, the biggest impediment in this space is the lack of new talent familiar with the environment.
I would actually not mind learning COBOL and writing boring bank software, but why bother if I can make more money with C++ and Python, while working on more interesting stuff?
If I'm going to take a pay cut to use an exotic language, I'm going to find a job writing Lisp.
Makes you wonder what would happen if the entire mainframe tech organization at one of these banks demanded to be paid on par with the traders working on the investment side of the bank.
It's for organizations like this where I really see unions making sense.
But it's not easy and not cheap.
The problem for the banks is that they have so many systems, typically thousands, and they are all interconnected.
Enter the 'enterprise architects' that draw power points with boxes and buses on top of all the old shit and you have a receipt for a very expensive soup.
Almost seems to be more of a vendor lock-in issue than an a mere 'old and scarce platform' issue, albeit that's significant also.
-----8<-----
A well-designed System Z emulator that allows users to migrate their own mainframe applications to commodity hardware would obviously pose a serious threat to IBM's mainframe business, but IBM's software licensing terms have historically prevented such a threat from materializing.
...
In many ways, the project arguably benefits IBM by encouraging interest in the mainframe platform. [...] What brought about IBM's change in perspective was an unexpected effort by the TurboHercules company to commercialize the project in some unusual ways.
TurboHercules came up with a bizarre method to circumvent the licensing restrictions and monetize the emulator. IBM allows customers to transfer the operating system license to another machine in the event that their mainframe suffers an outage. Depending on how you choose to interpret that part of the license, it could make it legally permissible to use IBM's mainframe operating system with Hercules in some cases.
Exploiting that loophole in the license, TurboHercules promotes the Hercules emulator as a "disaster recovery" solution that allows mainframe users to continue running their mainframe software on regular PC hardware when their mainframe is inoperable or experiencing technical problems. This has apparently opened up a market for commercial Hercules support with a modest number of potential customers, such as government entities that are required to have redundant failover systems for emergencies, but can't afford to buy a whole additional mainframe.
-----8<-----
So if they don't like herculeas' efforts they should've brought out their own, or come to some kind of arrangement with them.
They rarely have dedicated training systems given the cost of running them, and trying to find information from IBM was an excercise in frustration.
Personally I think that is where IBM made a huge mistake. Lack of low cost training systems has starved their ecosystem of new coders.
Description: OpenCOBOL is an open-source COBOL compiler. Homepage: http://www.opencobol.org/
Library Dependencies: gmp, libtool, db44, ncurses, libgnugetopt, libiconv, gettext, mpfr Platforms: darwin License: GPL-2+ Maintainers: egall@gwmail.gwu.edu, openmaintainer@macports.org