Live data from Hacker News

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

reuters.com

61–70 of 361 posts

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

#61

I've worked in the financial sector as recently as 2006. Without getting too specific, some of the financial systems I worked on underpin large sectors of the economy, across many banking chains. While Java was starting to take over these systems, thankfully the banks and regulators were hedging their bets on JEE with the knowledge that someone would eventually have to take over these systems. They were starting to t…

Anecdotal, but my friend knew VP of Information Technology at one of the big 4 banks in Canada really well. The VP told my friend to learn COBOL and if he passed the interview, they give you a blank paper where you write down your salary.

What this VP should have been doing was figuring out how to get out of that scenario entirely.

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

#62
post #45
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...

The IBM EXEC 2 manual (second edition 1982) is an interesting scan/read too.

http://bitsavers.trailing-edge.com/pdf/ibm/370/VM_SP/Release...

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

#63

Earlier quoted context omitted.

Anecdotal, but my friend knew VP of Information Technology at one of the big 4 banks in Canada really well. The VP told my friend to learn COBOL and if he passed the interview, they give you a blank paper where you write down your salary.

What this VP should have been doing was figuring out how to get out of that scenario entirely.

Well VP could have been exaggerating a bit as well since we were uni students back then and my friend was doing his internship there. He knew the VP through robotics.

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

#64
post #9

Earlier quoted context omitted.

They still teach COBOL and RPG at my old tech school. Went through the class and the tech behind the old mainframes are actually pretty neat. multi CPU processing, dynamically choosing which resources to use, easily transferring work to other machines and how everything works together so tightly. Just a lot of concepts that are getting 'rediscovered' instead of just looking at systems older than me (properly the same…

A few concepts such as having redundant CPUs introduced a lot of technical challenges without clear pay outs. The previous inspiration was the comparably high cost of computing equipment. Redundancy techniques such as those inspired by the block chain, seem to be much hipper now days.

When I peeked into mainframe development in college, it seemed like a lot of those technically heavy features were implemented because some manager said so, and someone else was willing to pay for it, no matter the practicality (or cost).

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

#65

Earlier quoted context omitted.

A lot of COBOL stuff is cut and paste crap, or just updating basic fields. There are people paying as little as $35/hr for these types of people, although most of the people at that rate are barely qualified to turn the computer on.

To be perfectly fair, turning on a mainframe or minicomputer is a nontrivial operation.

Any particular reason why?

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

#66
post #31

Earlier quoted context omitted.

At my last employer, there were a few "mainframers" (we called them). I was curious so I would ask my mainframer coworker how things worked on his end. I always struggled to understand, because it seemed everything was different ... the terminology, the culture, the ideas. I couldn't use analogy to tie what he was describing back to what I knew.

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 frequently say that IBM sells websphere to assure that they continue to sell mainframes. Because everyone knows if your going to replace your mainframe, you need to rewrite it in java, and what better framework than one provided by IBM! Then when the whole project ends up taking 100x the hardware IBM can pretend there is some secret sauce in those mainframes.

But, to the linked answer. While the details differ a bit, the zseries is simply a low level description of how the machine worked (past tense because modern zseries mainframes have a lot of hidden "virtualization" in order to leverage industry standards). That is why "mainframes" outperform racks of x86 PCs. There really isn't anything magical about the hardware. The real magic is the fact that the software is written by guys who grew up understanding how to processes transactions in a couple K bytes of memory, and the machines grew, as the transaction load did. The result is code which understands the hardware and is crazy optimized in the critical paths. The fact that frequently the critical paths all fit in a fraction of a modern L1 cache doesn't hurt either.

More specifically to your link. While the details vary a bit, modern PC hardware doesn't conceptually differ that much from mainframes. You could just as well ask the same question of a modern PC... Sure you can open a file and treat it as a stream of records, but unless you make sure to size your records on a multiple of 4k (was 512 until recently, although RAID controllers complicate things, as does flash) you will have read/modify/write cycles rather than simple write cycles. Plus, depending on your access method, the kernel may get involved and bounce buffer everything rather than DMA'ing directly to/from the page storing the data. Yah sure, the track/sector meta data on a modern hard-drive varies a bit from the answer given, but you might find a modern SSD that compresses its read/write operations doing things far closer to what was described. So, given a machine with a couple K of memory. You need something that today we would consider the front-end (html/javascript), back-end business logic, database, OS, drivers and disk firmware all in a single piece of code. What would it look like? Yah, all those layers would collapse, and your database records would look a lot like the disk sectors...

For something even closer, you could consider the options to tar, and modern tape drives which continue to actually support the concept of fixed vs variable block reads/writes and blocking factors, and with recent encryption standards even allow what is effectively per block metadata.

My point is that while a lot of the terminology and things exposed on a daily basis with a mainframe seem strange to someone at first glance, a modern server has just as much (if not far more) strange behaviors buried it in. The difference frequently are the layers of standardized interfaces, protocols, and software stacks layered below what most people consider their "software stack".

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

#67
post #40

"Experienced COBOL programmers can earn more than $100 an hour when they get called in to patch up glitches, rewrite coding manuals or make new systems work with old." Any contract-based engineer would charge that, or more, regardless of the language. Fortune 500 companies are happy to pay $300 / hour to a consulting company for engineering time.

They don't give the context. Maybe that's $100/hr w2 for the end contractor after the "Cobol Cowboys" company takes their cut. Also, it's Dallas, where cost of living is great. 2300 sq ft houses on decent lots in good school districts for $250k.

(Tangent: The Dallas of >3 years ago had a good CoL. Everything has gone up $100k+ since and it's still going... Those same houses are 400k now. And new homes have tiny lots.)

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

#68

Earlier quoted context omitted.

We have 50,000 lines of RPG code we need to replace over the next decade. Since the last RPG dev at our company is over 65 years old and can retire at any moment. It's going to be funny when we replace it with Java and our business guys ask why it runs much slower.

I never wrote RPG code, but 50k LOC seems a pretty small project to me...

It might be small, but I doubt it is. I am really curious what kind of test suite an RPG program would have. If it doesn't have a test suite then good luck because you're basically rewriting a decades old 50K line program and its behavior by guessing how it works. Also who knows what kinds of weird data formats or protocols it deals with that no libraries exist for in other languages.

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

#69
post #31

Earlier quoted context omitted.

At my last employer, there were a few "mainframers" (we called them). I was curious so I would ask my mainframer coworker how things worked on his end. I always struggled to understand, because it seemed everything was different ... the terminology, the culture, the ideas. I couldn't use analogy to tie what he was describing back to what I knew.

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

Unix has a few tricks up its sleeve from when it wasn't the top dog. I hesitate to ever recommend perl, but pack [1] and unpack are pretty sweet for this kind of stuff.

I only learned about them when a state sent me files in EBCDIC [2]. As with all things perl, you can convert from that to ASCII as a one liner. Or, rather, i helped someone much smarter than me do that, 20 years ago.

[1]http://perldoc.perl.org/functions/pack.html

[2]https://en.wikipedia.org/wiki/EBCDIC

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

#70
post #31

Earlier quoted context omitted.

At my last employer, there were a few "mainframers" (we called them). I was curious so I would ask my mainframer coworker how things worked on his end. I always struggled to understand, because it seemed everything was different ... the terminology, the culture, the ideas. I couldn't use analogy to tie what he was describing back to what I knew.

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

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 deflate algorithm, or tar file format, or any number of on-disk storage formats and you'll find they all (well, definitely most) do this, because it's the most efficient way.

Fixed length records are less common tor interchange formats, but likely you use them every day anyway. That's what databases often use, and the reason is because it makes it very efficient to index intro the structure and get whole records (know your data is sorted? Binary search is possible and easy then). Sometimes it's just the indices that are stored this way (they essentially have to be), but you can get fairly efficient table access out of some engines without indexing everything if all the records are fixed and the engine can determine that.

If you generally don't program in a low level language, this is generally abstracted away by some library that is written in that language. People do't usually write PNG and JPEG libraries in pure Python or Ruby (or at least, they don't expect them to be used much in production), they write a shim that wraps libpng or libjpeg.

Post reply on HN