Hmm, interesting. My bet is that the Java devs were not great at implementing concurrency. But who knows.
What Happens When You Mix Java with a 1960 IBM Mainframe
21–30 of 84 posts
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#22Is 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…
The picture of an IBM 7074 is from Wikipedia.
IBM offered 7074 emulation as a standard IBM System/360 product.[1] On an S/360, it required some special hardware support. In 1972, IBM gave users a free IBM 7074 emulator, software only, for System/370 machines.[2] They may still be running that program on a Z-series mainframe.
[1] http://bitsavers.trailing-edge.com/pdf/ibm/370/compatibility...
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#23The 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.
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
#24Is 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 100% buy they're using 1960s hardware. I've talked to some people who had to spend half their day on ebay trawling for parts to keep their ancient systems running. I've personally worked with medical offices still using 1970s hardware, it's not that rare. Many places have an "if it ain't broke don't fix it" attitude.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#25Is 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 100% buy they're using 1960s hardware. I've talked to some people who had to spend half their day on ebay trawling for parts to keep their ancient systems running. I've personally worked with medical offices still using 1970s hardware, it's not that rare. Many places have an "if it ain't broke don't fix it" attitude.
And it's an open question whether or not that attitude is better. A day or two of office admin time every 3-6 months is quite possibly more cost effective than hiring one of us for weeks/months/years to create a new system...
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#26Earlier quoted context omitted.
I 100% buy they're using 1960s hardware. I've talked to some people who had to spend half their day on ebay trawling for parts to keep their ancient systems running. I've personally worked with medical offices still using 1970s hardware, it's not that rare. Many places have an "if it ain't broke don't fix it" attitude.
And it's an open question whether or not that attitude is better. A day or two of office admin time every 3-6 months is quite possibly more cost effective than hiring one of us for weeks/months/years to create a new system...
Especially in a doctor's office where artificial supply restrictions on degrees and licensing give them little or no competition for clients.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#27I 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? :)
… or organizational culture? A lot of places really wanted to believe the problem was the technology because that's relatively much easier to change than going to a bunch of very senior managers and telling them that the way they're used to doing business is too expensive to continue.
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#28I'm still struggling with my own legacy code problem. I'm reviving an old LISP program from the early 1980s. Parts of it were written for the original Stanford AI Lab SAIL system in the 1970s. It last ran under Franz LISP in 1986.
My current struggle is with one line of code:
(defun getenode (l) (cadr l))
I'm converting this to Common LISP, which has real structures, but not hunks. That, with some new macro support, works for the regular structure operations. So far, so good.
But which element of the structure does (cadr l), which usually means the same thing as "(car (cdr l))", access? (cadr (list 0 1 2 4)) returns 1, so you'd think it would be field 1 of the structure. But no. It's more complicated and depends on how hunks are laid out in memory.
The Franz LISP manual from 1983 [2] says "Although hunks are not list cells, you can still access the first two hunk elements with cdr and car and you can access any hunk element with cxr†." At footnote "†", "In a hunk, the function cdr references the first element and car the second." This is backwards from the way lists behave.
A blog posting from 2008 about MacLISP says "A Maclisp hunk was a structure like a cons cell that could hold an arbitrary number of pointers, up to total of 512. Each of these slots in a hunk was referred to as a numbered cxr, with a numbering scheme that went like this: ( cxr-1 cxr-2 cxr-3 ... cxr-n cxr-0 ). No matter how many slots were in the hunk, car was equivalent to (cxr 1 hunk) and cdr was equivalent to (cxr 0 hunk)." Note that element 0 is at the end, which is even stranger. The documentation is silent about what "cadr" would do. Does it get element 2, or get element 0 and then apply "car" to it?
The original code [3] contains no relevant comments. I'm trying to figure out from the context what the original author, Greg Nelson, had in mind. He died in 2015.[4]
[1] http://www.mschaef.com/blog/tech/lisp/car-cdr.html [2] http://www.softwarepreservation.org/projects/LISP/franz/Fran... [3] https://github.com/John-Nagle/pasv/blob/master/src/CPC4/z.li... [4] https://en.wikipedia.org/wiki/Greg_Nelson_(computer_scientis...
Re: What Happens When You Mix Java with a 1960 IBM Mainframe
#29"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
#30When I first saw the Chromebook, my thought was that Larry Ellison's 1998 dream of a network computer thin terminal had come true. It's smarter than a true thin terminal, but everything lives in the cloud (err, butt).
That Chrome extension is clbuttic.