Banks scramble to fix old systems as IT 'cowboys' ride into sunset • Hacker News Board

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

#301

Post by BillWoodger » Tue, Apr 11, 2017, 10:11 PM UTC

Fuzzwah wrote: post #45

nsxwolf wrote: post #31

Earlier quoted context omitted.

You got that right. I had to deal with an interesting banking file format and I asked a question on Stack Overflow and got this gem of an answer. I politely accepted it as the right answer but boy oh boy does it feel like it's from an alien civilization. http://stackoverflow.com/questions/28640159/what-is-the-diff...

I just lost a chunk of time checking out the user who supplied the answer: http://stackoverflow.com/users/1927206/bill-woodger This one was great: http://stackoverflow.com/questions/15008999/can-anybody-tell...

Thanks for looking, I hope you didn't feel it lost in a bad way :-)

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

#302

Post by BillWoodger » Tue, Apr 11, 2017, 10:19 PM UTC

tyingq wrote: post #100

kbenson wrote: post #70

Earlier quoted context omitted.

Am I missing something? That doesn't seem all that odd, but perhaps that's because I'm familiar with IP,TCP and UDP and I've written something to read PNG headers before. Interchange file formats often include variable length blocks, which a part of the header defining the block length. That first part of the record is just a very small header per item, which defines the type of item and the size. Look into the defla…

>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…

As to the interchange of data, unless you run into a bunch of lazy Mainframers (they do exist) there's a lot they can do at almost zero "cost" to make it easy for you. It is not often there is a genuine case that anyone outside the Mainframe needs to know about internal Mainframe formats. I rail against "how do I translated packed-decimal fields in language-x" questions. There's no need for them to be seen. Same with LRECL and RECFM. Text-only, explicit signs, explicit decimal-points (or scaling factors), then you can have delimited records and no worries. You can even have XML or JSON if happier with that.

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

#303

Post by BillWoodger » Tue, Apr 11, 2017, 10:23 PM UTC

charlieflowers wrote: post #94

nsxwolf wrote: post #31

Earlier quoted context omitted.

You got that right. I had to deal with an interesting banking file format and I asked a question on Stack Overflow and got this gem of an answer. I politely accepted it as the right answer but boy oh boy does it feel like it's from an alien civilization. http://stackoverflow.com/questions/28640159/what-is-the-diff...

I read expecting to see something really alien. But it doesn't strike me as alien so much ... just low-level. You have to know the format of the bytes that were written to disk, which is pretty rare these days outside of systems programming (and mainframes I guess).

You don't have to know, and many working on Manframes don't. No-one outside the Mainframe should need to know, unless you get the stupid "oh, but they refuse to change the program" for a data-transfer (read, "we signed-off on it before we knew what we were doing"). There's 256 bit-patterns to a byte. It is not rocket surgery.

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

#304

Post by tyingq » Tue, Apr 11, 2017, 10:28 PM UTC

BillWoodger wrote: post #300

tyingq wrote: post #251

Earlier quoted context omitted.

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 throu…

"When, exactly, do you think that the X86 surpassed the Mainframe processors, and in what particular way?"

Fairly recently. Through things like affordable ssd, enough Moore's law around intel, and better distributed data stores. And better app side knowledge on how to break up a monolith.

I was around for a few failed "rewrite this TPF system" attempts and I saw what broke.

Commodity stuff can replace it now...but only very recently.

Or if you just meant x86-64 vs any other CPU, for the CPU alone? That debate is just done. They poured enough money into that mess that they won, assuming you don't care about power consumption.

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

#305

Post by movedx » Tue, Apr 11, 2017, 10:49 PM UTC

nstj wrote: post #77

movedx wrote: post #56

Earlier quoted context omitted.

Not sure if the $100/hour figure quoted is a hard and fast cash amount banks strictly adhere to, but ultimately this is business, so: set your price and walk away if it's not met. I set my price: AUD$850/day, with a TINY bit of wriggle room, and that's final. I know my worth (from a skills perspective and market/economical one.)

You could probably charge higher - this is at the mid range of many client side programmer daily rates in AU and systems skills like this are so much more critical.

Maybe. I'm a DevOp, not a coder. I could charge more.

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

#306

Post by nickpsecurity » Tue, Apr 11, 2017, 10:52 PM UTC

WorldMaker wrote: post #296

nickpsecurity wrote: post #177

Earlier quoted context omitted.

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

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

Oh my goodness... why do I keep making jokes about how a ridiculous world would function and then reality is already halfway there?! It's been happening too often past two years.

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

#307

Post by bananaboy » Tue, Apr 11, 2017, 11:51 PM UTC

lacampbell wrote: post #74

bananaboy wrote: post #57

Earlier quoted context omitted.

What's a basic IT contractor? $100 seems to start getting to the upper end of what I'd call a basic IT contractor. > $100 seems to be for more management/architect type roles according to http://au.hudson.com/portals/au/documents/salary%20guides/20... and http://www.greythorn.com.au/media/greythorn/greythorn%20mark... .

Don't most contractors use recruiting companies when they start out, then rely on word of mouth/networks? Might be why the hudson/greythorn rates seem low.

Hm, yeah that could be true. I think the big organisations like the banks, insurance companies, super companies, Telstra, NBN etc don't often take on contractors directly either.

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

#308

Post by sedachv » Wed, Apr 12, 2017, 12:31 AM UTC

UweSchmidt wrote: post #102

movedx wrote: post #54

Earlier quoted context omitted.

I smiled at your last comment. You're clearly a charming individual :-) Out of interest, what's the solution here? With your experiences in mind, what are the banks doing wrong from a technological perspective? I get the impression banks should almost start again on the side, building a completely new bank they then (manually?) move customers over to, or just use to take in new customers whilst waiting for the previo…

You can't wait for customers to "die out" as their mortgages will go on for decades. You definitely need a customer's old data in the new system. Now you have to maintain and develop two systems - bugs, banking regulation require constant work. Often the clock is ticking for old systems and asking vendors to provide and maintain ancient tools can be expensive or impossible. You can't "manually" move customers over, y…

For an example of how this system switchover looks like, First Bank in the United States just did a whole-system switchover in March, at least for their business customers. They handle my wife's business' banking, which means I do all the paperwork, and it definitely was a pain. Basically it was like signing up for a whole new bank account. They copied over something like only the last 6 months of transactions and some payroll info, but things like automatic bill payments and everything else (even basic online login) had to be set up again.

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

#309

Post by ice109 » Wed, Apr 12, 2017, 2:43 AM UTC

aeorgnoieang wrote: post #294

beat wrote: post #284

Earlier quoted context omitted.

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.

that's disingenuous. anyone can do anything given enough to learn the skills. what OP is asking is how many of today's programmers have the skills already. the answer is very few.

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

#310

Post by throwaway7645 » Wed, Apr 12, 2017, 3:38 AM UTC

ghostly_s wrote: post #239

liveoneggs wrote: post #204

Earlier quoted context omitted.

> As of the 2010 census, the ethnic makeup and population of San Francisco included: 390,387 Whites (48.1%), 267,915 Asians (33.3%), 48,870 African Americans (6.1%), 4,024 Native Americans (0.5%), 3,359 Pacific Islanders (0.4%), 53,021 from other races (6.6%), and 37,659 from two or more races (4.7%). > Atlanta 2010 census: 211,365 Whites (38.4%), 28,071 Asians (5.1%), 286,126 African Americans (54.0%), ... So you me…

Pretty sure when the OP referenced 1/2 acre backyards and $130k-$200k they were not talking about Atlanta.

True. Mostly anywhere in Louisiana, Arkansas, many parts of Texas, and probably all of Alabama and Mississippi. I also don't see large racial issues in my community with the exception being what happened in Baton Rouge last year. Something the South is historically bad at is education. I think we have the 5 lowest scoring states.