What Happens When You Mix Java with a 1960 IBM Mainframe
31–40 of 84 posts
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#32This article was such a pleasant surprise! I loved talking at Systems We Love and I love talking about legacy architecture in general. Bryan and the Joyent team were very accommodating and understanding. The White House is an amazing place to work (even now), but it's not a system that understands conference talks very well. Wish we could have a video, but it was a heavy lift just getting the bureaucracy okay with th…
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#33Is someone in the US government really still using an IBM 7074? Really? I'm shocked. How could that possibly be cost-effective? Actually, this blog post makes the story clearer: http://nikhilism.com/post/2016/systems-we-love/ It isn't a physical IBM 7074. When it came time to migrate from 7074 to S/360, rather than rewriting their 7074 software, they just wrote a 7074 emulator for S/360. And, it sounds like, they are…
At my last job as a consultant someone made https://github.com/manheim/antimony for testing IBM TN5250 mainframe screens in Ruby - it's like Selenium but even more brittle. :>
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#34Interesting problems not terribly well described in the post, would love to read more.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#35Earlier quoted context omitted.
>> They tried to rewrite the core apps but it was impossible to do so and get the performance. Well, Cobol is a bit like the C of mainframes - you can manipulate memory directly and so on. You can't really do that sort of thing with Java.
a) if it was really running on the old hardware; in that case ruby on a modern machine would have been several magnitudes faster than the original code - at least because of the faster IO b) if the whole thing was indeed running in an emulator, the emulation overhead would have negated all direct memory access advantages
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#36I have heard from many of my friends about massive projects of 'modernizing' mainframe applications with Java stack. Java did not deliver improvement that management was expecting. Once the project consumed all the budget for ~25% completion, they were scrapped. I think, though without any proof, that overreliance of 100s of mixed quality libraries, combined with 'best practices' of enterprise development and heavy a…
Was it Java that did not deliver improvement, or was it the team? :)
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#37"It used magnetic-core memory (instead of cathode ray tubes) according to Bellotti" I didn't think magnetic-core memory and CRTs were interchangeable...
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#38Is someone in the US government really still using an IBM 7074? Really? I'm shocked. How could that possibly be cost-effective? Actually, this blog post makes the story clearer: http://nikhilism.com/post/2016/systems-we-love/ It isn't a physical IBM 7074. When it came time to migrate from 7074 to S/360, rather than rewriting their 7074 software, they just wrote a 7074 emulator for S/360. And, it sounds like, they are…
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#39Hmm, interesting. My bet is that the Java devs were not great at implementing concurrency. But who knows.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#40Earlier quoted context omitted.
a) if it was really running on the old hardware; in that case ruby on a modern machine would have been several magnitudes faster than the original code - at least because of the faster IO b) if the whole thing was indeed running in an emulator, the emulation overhead would have negated all direct memory access advantages
Emulators on mainframes are much more sophisticated and performant than is typical on x86 and ARM platforms. The hardware and even software is often designed with emulation in mind, not just for backwards compatibility but for forwards compatibility, too.