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

281–290 of 361 posts

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

#281

Post by Clubber »

jmknoll wrote: post #125
sanguy wrote: post #52

Been working on accounting systems in RPG and COBOL since ~1992. I also know C/X86ASM/Pascal/Delphi/VB/Fortran. Never bothered with C++ that much; played with Java a bit but Oracle irritates my bowels so moved away from that. As mentioned in the article it's good work; but it is also not easy work. You tend to go through cycles of being pushed out to brought back under extreme emergency at any costs to get stuff work…

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…

No, the stuff you know will be ancient soon enough. I would recommend keeping up with the new way of doing the same ole shit though.

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

#282

Post by xenadu02 »

ternaryoperator wrote: post #108
acchow wrote: post #93

Earlier quoted context omitted.

> high 6 figures a year without working too hard Wow, like $800-900k?

I expect he meant the high range of 100K-200K. It's a colloquialism I hear periodically. I took it to mean $180K-$200K.

You can make $250/hr consulting for mobile app development. I have no doubt an expert in some ancient Cobol-based banking software can set their own price. When your entire business stops when it breaks paying $1000/hr is chump change by comparison.

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

#283

Post by defined »

skissane wrote: post #137
defined wrote: post #78

Earlier quoted context omitted.

Although I was never a mainframe programmer per se, I did quite a bit of interfacing between mini/microcomputers and IBM mainframes, so I got to see under the hood a little. (If I write something stupid, it's either memory issues or ignorance). I recall seeing how files were allocated on disk (remember that mainframes have many different OSes, like OS\390, and even OSes on top of OSes like VM/CMS, and I don't remembe…

> In this particular case, a file was preallocated in JCL to use N extents starting on a specific cylinder. Fixed size. Sounds like a z/VSE system (formerly known as VSE/ESA, VSE/SP, DOS/VSE, DOS/VS, DOS/360). In DOS JCL (which is a different syntax to z/OS / OS/390 / MVS / OS/VS2 / OS/360 JCL), you manually allocate files to disk locations using the EXTENT statement. By contrast, in z/OS the operating system decides…

Thanks for this! I had a number of interactions over the years with the S/3x0 world, and I wasn't always sure what was under the hood. I was aware that there was a bewildering slew of xxAM access methods, but had no chance to look into them.

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

#284

Post by beat »

ska wrote: post #271
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…

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 a lex/yacc parse stream, or handle socket programming or DOS HIMEM?

Improvement needs to be continuous. The ability to update individual parts of the system with minimal coupling is vital. But even keeping that as the system evolves is a challenge - and designing for it in advance leads to all sorts of unnecessary "just in case" abstractions in the code.

Keeping code alive and running for a generation is a whole different kind of challenge.

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

#285

Post by defined »

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…

I am very glad that Hercules is still around.

Kudos to those intrepid enthusiasts who implemented it and kept it going all these years. It's sad that they weren't able to capitalize on their efforts, but as a F/OSS supporter, I thank them for giving us at least the potential to play with mainframe technology (without running mainframe-compatible hardware).

Fun thought: I wonder what it would take to layer Hercules directly over ESX/i to create a poor person's "mainframe VM"? I mean, besides installing Hercules on a Linux guest on ESX/i.

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

#286

Post by eru »

user5994461 wrote: post #216
eru wrote: post #187

Earlier quoted context omitted.

Google is willing to hire anybody who can solve a few basic algorithmic problems.

The hardest part of Google is to be accepted for an interview, which they won't. The second hardest is to actually answer the questions in the interview, at that they don't stand a chance. Don't overestimate a guy who is doing a job reorientation from a random degree, having barely touched a computer before. Last but not least, Google is only in a handful of locations in the World, banks are more common.

The trick to get your interview at Google is to get somebody to refer you. (And that's not that hard. If you can't find a Googler in person at a meetup, hang out online and write to a few random Googlers. They get a hiring bonus, so if you provide them with the information they need (it's a small questionnaire about you they have to answer plus your CV), lots of them are happy to refer you.)

The interview is a bit peculiar, and not all that correlated to what even Googlers do on their day job, but it's trainable, and you can repeat every year.

Do Facebook at the same cadence, but six month out of phase, and you got a steady stream of interviews. Add eg Microsoft and some other companies, and you are virtually guaranteed to land a decent job at some time. And that holds even after I agree with your caution about overestimating a random but intelligent person. It is quite the time commitment, though.

The locations weren't too much of a problem for me. But I do have to admit that when I joined my preferred location of Singapore didn't really have any engineers, so I settled for Sydney. And as your comment suggests, yes, I was working for a bank in Singapore before.

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

#287

Post by eru »

grogenaut wrote: post #274
eru wrote: post #186

Earlier quoted context omitted.

Might still be a good decision: the corporate politics get so much harder, once you have in-house teams. And: that company would probably fail at writing in-house software---most of them do.

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?

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

#288

Post by user5994461 »

eru wrote: post #286
user5994461 wrote: post #216

Earlier quoted context omitted.

The hardest part of Google is to be accepted for an interview, which they won't. The second hardest is to actually answer the questions in the interview, at that they don't stand a chance. Don't overestimate a guy who is doing a job reorientation from a random degree, having barely touched a computer before. Last but not least, Google is only in a handful of locations in the World, banks are more common.

The trick to get your interview at Google is to get somebody to refer you. (And that's not that hard. If you can't find a Googler in person at a meetup, hang out online and write to a few random Googlers. They get a hiring bonus, so if you provide them with the information they need (it's a small questionnaire about you they have to answer plus your CV), lots of them are happy to refer you.) The interview is a bit pe…

Yes, it's good advice, I know how this works. Meetups and linkedin messages.

You still need to be in a google location to come across a meetup (there are only so few offices in the world) and your profile might need to be better than "I dropped from art school last month. I like computers."

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

#289

Post by ska »

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…

I agree on the continuous improvement - i wasn't suggesting you do this once and stop thinking about it.

But note, 25 years we didn't have the same solutions we might have today, but we had good solutions to lots of common problems. We certainly had solutions to "system is specified by a mixed bag of ASCII and inconsistent EBCDIC files, none alike, all specified 15 years ago. Which is at the heart of the problem OP posited. 25 years ago people were saying exactly the same thing about banking systems in COBOL that beat describes. Exactly. The batch processing OP discusses had already been out of vogue for a decade at least. We had good solutions for nearly all of these problems, what we didn't have was quick, cheap solutions.

Just for completeness: we had html. We'd had SGML for a decade (which begat HTML and later XML). We had reasonable streaming protocols. We were a lot worse at connecting heterogeneous systems controlled by different entities and interoperating, but we good at networking and building distributed systems at a smaller scale.

Keeping code alive and running for a generation is a very difficult problem, but keeping systems tidy, modular, and evolving is manageable, until you let them go too much.

And people are digging the same holes today. It's not technology that is the cause, it never was. It's cost and short term planning.

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

#290

Post by eru »

user5994461 wrote: post #288
eru wrote: post #286

Earlier quoted context omitted.

The trick to get your interview at Google is to get somebody to refer you. (And that's not that hard. If you can't find a Googler in person at a meetup, hang out online and write to a few random Googlers. They get a hiring bonus, so if you provide them with the information they need (it's a small questionnaire about you they have to answer plus your CV), lots of them are happy to refer you.) The interview is a bit pe…

Yes, it's good advice, I know how this works. Meetups and linkedin messages. You still need to be in a google location to come across a meetup (there are only so few offices in the world) and your profile might need to be better than "I dropped from art school last month. I like computers."

I never finished my degree..
Post reply on HN