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.
Banks scramble to fix old systems as IT 'cowboys' ride into sunset
61–70 of 361 posts
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#62Earlier 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...
http://bitsavers.trailing-edge.com/pdf/ibm/370/VM_SP/Release...
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#63Earlier 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.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#64Earlier 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.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#65Earlier 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.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#66Earlier 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...
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"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.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#68Earlier 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...
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#69Earlier 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 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.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#70Earlier 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...
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.