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

251–260 of 361 posts

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

#251

Post by tyingq »

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).

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 performance far outpaced the main processors in a mainframe.

I believe that advantage is completely gone now, but mostly via brute force vs elegance. Commodity hardware is just so fast now.

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

#252

Post by socmag »

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…

Early in my career in the 90's I worked for BZW working on derivative hedging for financial swaps.

Things were pretty hectic and it was a pretty small team. We were using SQL Server at best and Excel spreadsheets as information feeds at worst, trying to calculate Black-Scholes on this stuff.

I clearly remember talking to the Traders and Quants regarding certain calculations we were doing to give them bond price goals for offsetting risk on the trades.

Honestly the traders at least didn't give a crap. I would present them tables; they would look at it, and would say "yeah that looks about right" - that's a direct quote from BZW's lead trader in 1994. I can't imagine things have changed that much.

I didn't stay long in that environment; it was pretty clear to me that despite getting people like Grady Booch coming in to clean up our act our "Customers" didn't really care too much about the mechanics of how things worked, or even worse whether the calculations were correct.

Top and bottom is, while the banking industry may employ "Cowboys" in the back-office for IT services, they also employ Cowboys in the front-office making the trades.

I doubt that has changed for the better that much. See 2008 financial crisis et al.

[Edit] As a side note, for the time I was earning more money than I knew what to do with. My boss at the time felt so ambivalent about his twice yearly 50k (sterling) bonus that he threw it away at the Casino the day he got it, (remember, this is 1994). I left and took a 75% pay cut to go work for Microsoft on projects that were at least form a CS point of view a lot more respectable. Having said that, I don't want to come off too harshly, we were at the cutting edge at the time and the technology was very cool and thoroughly enjoyable. But still..

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

#253

Post by dpark »

binarymax wrote: post #247
dpark wrote: post #244

Earlier quoted context omitted.

Don't you then need to pay IBM for the OS anyway? Will they license the OS for this use? Or did your system actually include the OS source?

For 360, it is now in the public domain: https://en.wikipedia.org/wiki/OS/360_and_successors

Interesting. Thank for the details.

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

#254

Post by pnathan »

hourislate wrote: post #190
jmknoll wrote: post #125

Earlier quoted context omitted.

As a developer who recently turned thirty, I think about this a lot. I like working in startups, but its not going to fly forever. I'm already the old guy in the room. Would learning 'ancient' technology be a good career move? These systems aren't going anywhere, right? But the people who know how to maintain them are. Which means that maintaining these system, which already pays well, will pay even better in the fut…

I don't think you need to learn an "ancient technology". There is plenty of work in traditional corporations. You just need to find one that has legs so you can ride it out for the next 30 years. A steady job, 5 weeks of vacation after 15 years, benefits. If your lucky you can become a number and slowly disappear, spending more time doing your own thing. Long lunches, nap in the car, run some errands, etc. Eventually…

> Long lunches, nap in the car, run some errands, etc. Eventually everyone runs out of piss and vinegar. It's not so bad.

I hate working with people like that, and would hate myself if I did that.

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

#255

Post by kbenson »

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…

Sure, I wasn't trying to indicate there was no reason or benefit to mainframes, just to summarize the situation to make sure I understood it correctly. It does make sense to have an integrated library for advanced file access if you have dedicated IO hardware. That prevents a lot of misconfiguration of libraries that might try unsuccessfully use that system, if they even support it at all (i.e. OpenSSL and crypto hardware such as dedicated AES hardware as in the Via mini-ITX platforms of yesteryear).

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

#256

Post by fragmede »

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…

Startups have yet to solve the problem of legacy code. At the very center of Internet companies too old to still be called startups is some ancient Perl or PHP written by the founders, back when they were around, and even wrote code. That might seem less archaic than COBOL or faxes but it's the same root problem. "If it ain't broke, don't fix it" didn't account for "well you see, it's not catastrophically broken but it's holding us back"; maintenance programming isn't sexy, like maintaining bridges and highways that have already been built, but just as necessary for continued operation.

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

#257

Post by atria »

beat wrote: post #242
splintercell wrote: post #240

Earlier quoted context omitted.

Lol, I heard it differently, 'In South they are supposed to hate us in theory but not in practice, in north they are suppose to love us in theory but not in practice.'

I'm still waiting for the white people from the north to throw a fit because I said this. It's not always well received...

... but so true. I grew up in the South and am in an inter-racial marriage. After I moved up to a northern "blue" state, I met more overtly racists people than I thought possible. It was shocking.

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

#258

Post by pnathan »

skissane wrote: post #140
defined wrote: post #83

Earlier quoted context omitted.

This. Anyone who had doubts can get a stack of z/OS DVDs and the Hercules S/390 emulator and just try to get it to boot! Not trivial. Although I don't know if Hercules is still alive and hasn't been shut down by the suits.

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 companies, broadly, might be north of $100K. I can't speak to specifics, of course.

It's quite a reorientation of what "expensive" means when you get involved, even a bit, in corporate purchasing and negotiation.

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

#259

Post by kpil »

tyingq wrote: post #105
kpil wrote: post #99

Earlier quoted context omitted.

Because COBOL is the PHP of the 60s, and mainframes are slow and expensive. Also, too many of the talents are stuck in a blocked I/O mindset somehow. Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s

As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies. Cobol isn't involved, but those slow mainframes are.

To be fair, rewriting huge mission critical systems is hard, no matter of what kind of system it is and what you are changing to.

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

#260

Post by [deleted] »

tyingq wrote: post #105
kpil wrote: post #99

Earlier quoted context omitted.

Because COBOL is the PHP of the 60s, and mainframes are slow and expensive. Also, too many of the talents are stuck in a blocked I/O mindset somehow. Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s

As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies. Cobol isn't involved, but those slow mainframes are.

[deleted]
Post reply on HN