Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Banks scramble to fix old systems as IT 'cowboys' ride into sunset

reuters.com

Post reply on HN
Print view View original

291–300 of 361 posts

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#291

Post by inopinatus »

beat wrote: post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

Well, since I have also successfully managed similar such projects for financial institutions & telcos, and I live in startup land, by your last remark I feel moderately qualified to comment.

I'll challenge your view that folks in the startup world don't know enterprise. Maybe some visible fraction are the young and inexperienced hipsters as portrayed on HBO, sure, but most of those I know in CTO+ roles actually have a lot of enterprise under the belt. In my case in a B2B play it's practically mandatory, in order to understand the customer.

I believe enterprises suffer principally from the fear of change, or more bluntly, the fear of screwing up and being held accountable, which leads to the pathological technical debt issues you've described. So the problems I've always faced in enterprise projects are not primarily technological, but instead those of a) finding a full team of people competent enough and fearless enough to perform transplant surgery on the beating heart of a living body corporate and b) collecting sufficient clout to be allowed to perform the operation.

I reckon the best thing you can do, as a project leader in the enterprise world, is leave a legacy of constant and gradual change. Normalize frequent updates through CI/CD. Get business owners used to things like minor feature requests being included in daily deploys. No-one will thank you at the time, but a change in culture is almost certainly the most enduring value you can create.

So yeah, I'll happily roll my eyes at the "incompetence of the enterprise world", because I've dealt with the stupid head-on, and used techniques from startup land to innoculate it permanently.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#292

Post by skissane »

pnathan wrote: post #258
skissane wrote: post #140

Earlier quoted context omitted.

Open source Hercules is still alive. Attempts to commercialise it (TurboHercules) ran into legal trouble with IBM, but to my knowledge the open source Hercules project hasn't faced any issues. (Disclaimer: I'm not a lawyer, I don't work for IBM, etc.) IBM's licensing agreements don't allow you to run current versions of its mainframe OSes under Hercules. IBM will sell you an equivalent technology which you can legall…

> it is quite expensive (I have heard figures quoted like USD 5000). A bit of correction, I'm afraid. That's the cost for mid-shelf copy of Visual Studio 2009 or so. It's not expensive at all for corporate purposes at any company I've worked at. Top-shelf Visual Studio was set for 10,000 for a long time (some checking of current costs suggests they've redone their pricing model). Expensive software for functioning co…

Expensive for whom? Yes, for a large corporation USD 5,000 is easily affordable.

But consider someone like myself. My job isn't focused on mainframes. I very rarely have had anything to do with them at work. Even though my employer could easily afford USD 5,000 to buy me a zPDT if there was a business case for doing so, they won't because there isn't really one–in the last five years, I've only once had to help a customer with mainframe integration issues, and we used a partner company with mainframe specialists to handle that engagement for us. However, I'd still like to learn the technology. I'm not sure I'd ever really want a job in it, but it fascinates me. But I'm not forking out thousands of dollars of my own money just so I can play with z/OS or z/VM.

I think this is a problem with mainframes–even if someone is interested in the technology, it is very hard to learn about it unless your employer uses them (and in a large company, even if your employer does, your own job might still have little or nothing to do with them.) I would have thought IBM would be more keen on spreading knowledge of its own technologies around–it might actually make it easier to sell them to people–but it doesn't seem to be on IBM's radar. HP has the hobbyist program for OpenVMS, IBM could set up a similar program for mainframes (and IBM i too), but that has never happened. (I have heard some folks have tried to talk IBM into it, but they have never got anywhere.)

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#293

Post by Justsignedup »

beat wrote: post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

As my Director says: "Yes, we're solving problems and making code better, but never forget, this code has run the business for 10 years, so give it credit that it did do it's job."

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#294

Post by aeorgnoieang »

beat wrote: post #284
ska wrote: post #271

Earlier quoted context omitted.

I take it to mean they've never actually worked on a truly hard problem in their lives. I certainly have some empathy for this view. On the other hand, the right time to have addressed actually fixing some of these problems is 25 years ago. The second best time is today (to steal/abuse a phrase). Enterprise organizations sometimes punt these things down the road with half-assed solutions. It's cheaper today and tomor…

Sometimes, 25 years ago, a solution to the problem wasn't available. I worked on state-of-the-art systems from 25 years ago. We were writing homegrown streaming data protocols over raw sockets, parsed with lex and yacc. We didn't have ssh, we didn't have http, we didn't have xml (much less json). A world-class system from 25 years ago would be scrap today... how many bright young junior programmers today could update…

> how many bright young junior programmers today could update a lex/yacc parse stream, or handle socket programming or DOS HIMEM?

Almost all of them – if they're really "bright" anyways. Even given that a lot of the important context is missing, bright programmers can do this stuff.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#295

Post by Justsignedup »

inopinatus wrote: post #291
beat wrote: post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

Well, since I have also successfully managed similar such projects for financial institutions & telcos, and I live in startup land, by your last remark I feel moderately qualified to comment. I'll challenge your view that folks in the startup world don't know enterprise. Maybe some visible fraction are the young and inexperienced hipsters as portrayed on HBO, sure, but most of those I know in CTO+ roles actually have…

Furthermore lots of decisions in enterprises look like the following:

An executive is approached by a vendor. The vendor entices the executive, shows them a good time, gives them a really good assurance their service is worth it.

An engineer hates this service because it sucks. Because the decision was made based on how cool it looks, not by technical needs.

Given that, it is hard for an executive to get approached by a vendor who says "okay, this will cost a crazy amount of time and money but we'll make your systems more modern" which sounds like "hey, I'm going to come in and offer to replace a system that has worked for 30 years with something modern and potentially risky. And it'll cost you a lot." The executive doesn't (usually) realize that the true cost is really high and goes up with time. And of course they don't want to lose their cushy job so hell no they won't take it. Also the executive isn't directly working with the engineers so he doesn't truly know if he can trust them.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#296

Post by WorldMaker »

nickpsecurity wrote: post #177
CyberDildonics wrote: post #168

Earlier quoted context omitted.

I can't wait until I can compile Cobol for webasm

Nah, go with terminal apps in Visual COBOL distributed as Electron apps.

https://xtermjs.org/ is here for you.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#297

Post by grogenaut »

eru wrote: post #287
grogenaut wrote: post #274

Earlier quoted context omitted.

Good point. I didn't think about the leverage of having an internal team holding you hostage vs and external. And yes there is also the, how do you hire up a good dev team when you obviously don't know how to do software yourself. Eg hiring outside your competency. I know this is especially hard, and I've watched large companies who are good at hiring in general fail at it specifically in a wheel house. I think this…

Semi-related: that's why 'blockchain technology' can be so useful to banks. It's not that they need anything blockchain at all, but in practice CEOs are not actually all that powerful against the vested interests of middle management, but having the excuse of hyped up 'blockchain technology' can help with pushing through common-sensical reforms that you would want to do anyway. What's a wheel house?

It's the core of a baseball batter's hitting area. Eg their core strength.

Challenge for you since you invoked block chain: Come up with a situation where "the blockchain" wouldn't be a good fit.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#298

Post by WorldMaker »

avar wrote: post #131
defined wrote: post #81

Earlier quoted context omitted.

Please don't remind me. I had to convert the expat XML parser to compile on z/OS and work in EBCDIC, and found that round tripping between ASCII and EBCDIC was sometimes impossible because of the existence of not two, but THREE line terminator characters: CR, LF, and NL (0x85). Not to mention that you cannot test for uppercase or lowercase like the ASCII `ch >= 'A' && ch <= 'Z'` because they are not contiguous in EBC…

This is how you can implement isUpper() on EBCDIC: https://github.com/Perl/perl5/blob/v5.24.0/handy.h#L1153

IIRC, you should be able to do it easier than that: EBCDIC is not contiguous because upper-case versus lower-case is a (shift) bit-flag.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#299

Post by BillWoodger »

kbenson wrote: post #246
tyingq wrote: post #100

Earlier quoted context omitted.

>Am I missing something? The interesting part is that the fixed and variable record formats are first class things on the mainframe. So, something like DB2 on a mainframe can use system supplied functionality (VSAM) as their storage engine. As opposed to unix, where higher level databases like MySql, CockroachDB, etc either roll their own (InnoDB) or use some 3rd party offering like RocksDB, LevelDB, etc. VSAM isn't…

So I guess it's fair to say the difference is that the mainframes have a standardized format for record creation and consumption in the OS, sort of like DB2 being included in the kernel? That is nice, and it does explain why it might be confusing, even if I think it doesn't necessarily get you much over using a third party library (unless there are other benefits I'm not considering).

If you want DB2 in the operating system, you need an "IBM midrange" or iSeries. Much shorter code-path, much faster. If you want the fastest record access, the operating system z/TPF for the IBM Mainframe. Not only just fixed-length records, but jus fixed-length records of one size. Effectively, there are no "third-party libraries" (until you get to IBM's Java, or any language someone has ported (Lua is a popular example).

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#300

Post by BillWoodger »

tyingq wrote: post #251
kbenson wrote: post #246

Earlier quoted context omitted.

So I guess it's fair to say the difference is that the mainframes have a standardized format for record creation and consumption in the OS, sort of like DB2 being included in the kernel? That is nice, and it does explain why it might be confusing, even if I think it doesn't necessarily get you much over using a third party library (unless there are other benefits I'm not considering).

It's less of a difference now, and somewhat unrelated to the specific topic, but... A big historical difference with mainframes and data was the architecture around I/O. They always had separate processors to offload I/O, and I/O was always asynchronous. And things like VSAM were highly tuned to take advantage of that. That's why mainframes continued to outpace Linux/X86 for some types of workloads...even after X86 p…

Correct about the I/O. You can let the space-bar auto-repeat 1919 times, for instance (nearest equivalent to circling the mouse) and the CPU cost is... zero. When, exactly, do you think that the X86 surpassed the Mainframe processors, and in what particular way? Current generation (expect a new one this year) is 5Ghz (actually slower than the previous) and has lots of stuff. A fully-loaded box has a theoretical throughput of 30bn (yes, billion) RESTful transactions per day. And if that isn't enough power, you can hang another 31 boxes onto it and treat them as one.
Post reply on HN