What Happens When You Mix Java with a 1960 IBM Mainframe
thenewstack.io
What Happens When You Mix Java with a 1960 IBM Mainframe
1–10 of 84 posts
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#2The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library stacks, you went close to the metal and you coded in languages like Assembler, COBOL or FORTRAN. I/O was often run through specialised co-processors (such as IBM's channel processors) and the terminals could sometimes help too.
I have friends who have been looking after legacy applications for an airline running on Unisys. The core apps for reservation, Cargo booking and weight/balance were written in FORTRAN. In recent times, the front end was written in Java to give web access. They tried to rewrite the core apps but it was impossible to do so and get the performance.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#3[deleted]
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#4Is 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 still running their 7074 software, under their 7074 emulator, most likely on a recent z/Architecture mainframe.
The article makes it sound like people still use "1960s mainframes" when I very much doubt anyone is still running 1960s hardware in production. People use modern machines–modern IBM mainframes, which are multicore 64-bit processors–or other mainframe vendors such as Unisys or Fujitsu use mainly I believe x86-64 running Linux running a software emulator for the old mainframe CPU.
A lot of legacy, sure, but I think this article makes it sound even more legacy than it really is.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#5The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library stacks, you went close to the metal and you coded in languages like Assembler, COBOL or FORTRAN. I/O was often run through specialised co-processors (such as IBM's channel processors) and the terminals could sometimes help too. I have friends who have been look…
> The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed.
That's a common sentiment. I wish I could find the quote by someone who made the transition; it was about how happy they were to be able to compile so much quicker, and how getting immediate feedback made them so much more productive.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#6The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library stacks, you went close to the metal and you coded in languages like Assembler, COBOL or FORTRAN. I/O was often run through specialised co-processors (such as IBM's channel processors) and the terminals could sometimes help too. I have friends who have been look…
>> 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.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#7The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library stacks, you went close to the metal and you coded in languages like Assembler, COBOL or FORTRAN. I/O was often run through specialised co-processors (such as IBM's channel processors) and the terminals could sometimes help too. I have friends who have been look…
> The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. That's a common sentiment. I wish I could find the quote by someone who made the transition; it was about how happy they were to be able to compile so much quicker, and how getting immediate feedback made them so much more productive.
The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware.
I compile/assemble COBOL and IBM's assembly language on a z13 daily and it's pretty much instantaneous.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#8An explanation from 'bcantrill about why the talk was not recorded: https://lobste.rs/s/q2xz14/systems_we_love_videos/comments/i...
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#9Is 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…
I was going to ask if they couldn't just replace the hardware with emulators :-)
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#10Is 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…
I know of an S/360 assembly code base that (as of a decade ago), still ran code that assumed 24 bit address space and used 31 bit pointers with tags stuffed in the unused 7 bits. So it had to run in the lowest 16MB of memory, on a 64-bit machine. I don't think they had the budget to rewrite that subsystem to fix it. So yes, new hardware, but some of the legacy problems in the software run very deep.