211–220 of 361 posts
Earlier quoted context omitted.
Just hang around - the technologies you learnt when you were 20 will be ancient soon enough.
Yeah, but my impression is they're so ephemeral they might not have a big market share.
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
Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.
Earlier quoted context omitted.
What about not doing a rewrite? What about instead refactoring, documenting etc the old system.
If you want to move off of COBOL + mainframe, that kind of necessitates a rewrite, doesn't it?
Earlier quoted context omitted.
What about not doing a rewrite? What about instead refactoring, documenting etc the old system.
If you want to move off of COBOL + mainframe, that kind of necessitates a rewrite, doesn't it?
Earlier quoted context omitted.
We have most platforms from IBM, z (Mainframe), iSeries (AS/400), p (AIX), plus about everything windows. Moving off core systems (z/i/p) isn't simple mostly because of the amount of data combined with all the custom applications. every attempt to move the apps off the z don't come to fruition because of scope and the fact it just works. the i is increasing its load to pick up from the z and getting a good dose of we…
> Moving off core systems (z/i/p) isn't simple mostly because of the amount of data combined with all the custom applications. I wonder if someone could get away with selling a z/i/p emulator, akin to Wine. (Or perhaps more appropos, Mame, since the machine architecture would differ as well.)
Anyone using mainframes heavily in the way we are talking about here is probably running something mission critical with lots of $$$ tied into it - and the financial/legal risk of having anything go wrong at all is a huge driver - they want a big company with deep pockets and pages long support agreements backing them, so they can indemnify the other company if there is any problem and shift the blame (and from a personal perspective, cover their own butt). The mainframe using companies also usually have deep pockets, and so even if the mainframe is expensive, it still allows them enough profit margin to support it..
"There is a problem with our IBM mainframe, we have requisitioned a team of 12 people from IBM to investigate and legal is looking into what sort of contractual obligations IBM has if issues aren't resolved" is a much more palatable statement for the fortune-100 CIO to pass along to the CEO than "our IBM emulator seems to be having problems, but the 3 people developing it are on vacation, IT isn't sure if it's an emulator issue or something to do with the new hardware we migrated to run it on 2 years ago, and IBM says they don't support the software when it's run on the emulator. We're calling them again to see if there's some way we can convince them otherwise"
Earlier quoted context omitted.
Yes. Very likely that they can't get a better job. As the previous comment said, they are trained from scratch having no experience in tech whatsoever and mainframe is not remarketable to a web company.
Google is willing to hire anybody who can solve a few basic algorithmic problems.
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.
Earlier quoted context omitted.
What about not doing a rewrite? What about instead refactoring, documenting etc the old system.
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
$100 an hour, so $208k a year (assuming no time off), for a guy with 30+ years working on a critical system in an industry where floor traders can make 7-8 figures, and huge bonuses are paid to "analysts". I have plumber buddies that make more than that per hour (and with a crew can make more a year). That's why a couple years ago when I had access to a zseries, and was hearing about how "desperate" the banks were I…
The number one issues I have seen in the IT industry is lack of incentive, primarily in the form of salary, lack of respect, and lack of a C-level working on their behalf at the boardroom level. I know sysadmins who supported entire 200-250 person, 7 branch companies single-handedly, but get 40k, never had a budget, and got refused for hires and simple stuff like "hey, the cabling here is from the 1970's, we need a contractor to come in and recable the offices", and being told "no, you do it, at the same time you support the whole company, and no- you can't buy the TIA spec book."
It's no wonder companies are hemoragging good IT talent left and right.
If I could offer a single peice of advice to a company, it would be to create a CTO and CIO position if they don't exist, and get a good one who advocates on the behalf of the IT department. I see most of these issues as management failures first, not technical, so don't come crying about cobol to me.
And as long as you fit the "correct" demographics for living in the south.
> 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…
Earlier quoted context omitted.
all features and edge cases should have a test. if possible also have tests for all the bugs ever found in the old system. it helps if the tests are not too coupled with the code and are well documented. a test could be making an entry where deb and cred dont match. or trying to enter an extra decimal. and if the system adds two decimals corectly.
>all features and edge casss should have a test. Yeah, but the interesting problem is what happens next. Let's say a test case reveals that there's a flaw in the next-gen system. You fix it. It later turns out that the same flaw exists in the legacy system. What do you do? Do you revert the fix, or leave it in place?