Live data from Hacker News

What Happens When You Mix Java with a 1960 IBM Mainframe

thenewstack.io

61–70 of 84 posts

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#61
post #4

Is 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…

Mazal tov, that's containerization...from the 1970s.

Everything old is new again. I love our profession.

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#63
post #4

Is 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…

> A lot of legacy, sure, but I think this article makes it sound even more legacy than it really is. Indeed. The point of the talk was that 1) legacy is often assumed to be bad not for any real technical reasons but just because it is legacy and 2) a lot of what was being presented as legacy wasn't even legacy. Their OS 2200 version was actually newer than the Oracle DB they were using on the "modern" side of the sta…

You might enjoy this article given the kind of work you do:

http://www.pcworld.com/article/249951/computers/if-it-aint-b...

You've probably seen plenty of crazy stuff in legacy systems but I'm hoping at least one surprises you. Maybe the first one. :)

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#64
post #4

Is 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…

It's possible Ms Belotti and her team didn't realise they were working with an emulator. Mainframes being what they are, the programmers were probably never in the same room as the machines they were progamming, and it does take a bit of digging to figure out that the architecture you see before your eyes is emulated on another machine (like in "The Story of Mel"). Still, even the blog post you link to doesn't make i…

I believe (a coworker of mine worked on S/360) that all the old software can be effectively run through emulators on the current system z. The feeling was that once you had done the development and testing of an older system, IBM was never going to force you to rewrite your code. As a result, the upgrades were pretty seamless over the years. Many of those customers never had to upgrade and never had a reason to.

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#65
post #60
post #40

Earlier quoted context omitted.

Do you mean to say that they were running a mainframe emulator on a mainframe?

Compilers for some IBM mainframes have for decades (since the 1970s, I think) targeted an intermediate virtual machine instruction set which is then translated on-the-fly to the local architecture by the OS upon execution. So in the case of IBM their machines are truly built with both forward and backward compatibility in mind. The pointers for this instruction set have been 128 bits since the beginning, long before…

Excellent comment. I'll also point out that system z mainframes are not slow machines, so even with some emulation overhead there is typically enough performance.

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#66

I'm not sure the article did well answering the headline. I now know that there is a mainframe (emulator it seems from additional research) that returns API responses very quickly (1-6ms) TO a Java app... which apparently is inefficient as the page render takes 6-10 seconds. Interesting problems not terribly well described in the post, would love to read more.

Yeah it describes pretty basic "discoveries", and reads a bit like a book report. Would love some detail.

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#67
Did anyone read this and go "hu"?

There's this whole thing about how they are getting data from mainframes where "the data was being returned in between one and six milliseconds".

But then: "harvest that data from the magnetic tape and load them up into more traditional databases. That Java application was extracting the data from the databases"

But then: "But the data from the mainframes was actually arriving (from its new home in the database) in less than six milliseconds. The bottleneck was — of course — the Java application."

So of course it is entirely possibly to write slow Java applications. But then the story seems to end! So what happened? Did they fix the application?

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#68
post #4

Is 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.

I/O speed reported in the article seemed highly unlikely for mag tape

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#69
post #47

Earlier quoted context omitted.

See the link listed above: https://github.com/John-Nagle/pasv/blob/master/src/CPC4/z.li... I put all the code on Github. The oldest version of each file is exactly what ran in 1986. The code is delicate. It's a theorem prover, and there's much manipulation of complex data structures, with little explanation of what's going on. The overall theory is documented; this is the original Oppen-Nelson simplifier and there ar…

getenode is only called in a few places, and each call looks like: (getenode znode) i.e. getenode is only called on znodes. The definition of makeznode is: (defun makeznode (node) (prog (l znode) (setq l (list (list '(1 . 1) node))) (xzfield node (list l node nil)) (setq znode (tellz l node)) (or (null znode) (eq znode node) (break makeznode)) (return l))) So it seems like getenode is called on a regular list whose s…

I thought that way at first. But the program breaks when (getenode znode) is called on an item of type "node", not a list. This happens when (interntimes) takes the path which ends

    (or (setq znode (tellz l node)) (return t))
    (or (eq node (getenode znode)) (zmerge node (getenode znode)))))
and (tellz) has taken the path which ends (return (baserowz* i)). "baserow*" is an array which contains links to "node" items, not list cells. What "z.lisp" and "ze.lisp" are doing, by the way, is solving systems of linear inequalities by using linear programming on a sparse matrix.

Also, see

    (defun isznode (x) (and (hunkp x) (= (hunksize x) 8))) ; original

    (defun isznode (x) (equal (type-of x) 'node))   ; CL version
which indicate that znodes are hunks/structures, not lists. This is inconsistent, yet somehow it used to work.

(If you want to talk privately about this, I'm at "nagle@animats.com". Too much detail for HN.)

Re: What Happens When You Mix Java with a 1960 IBM Mainframe

#70
post #69

Earlier quoted context omitted.

getenode is only called in a few places, and each call looks like: (getenode znode) i.e. getenode is only called on znodes. The definition of makeznode is: (defun makeznode (node) (prog (l znode) (setq l (list (list '(1 . 1) node))) (xzfield node (list l node nil)) (setq znode (tellz l node)) (or (null znode) (eq znode node) (break makeznode)) (return l))) So it seems like getenode is called on a regular list whose s…

I thought that way at first. But the program breaks when (getenode znode) is called on an item of type "node", not a list. This happens when (interntimes) takes the path which ends (or (setq znode (tellz l node)) (return t)) (or (eq node (getenode znode)) (zmerge node (getenode znode))))) and (tellz) has taken the path which ends (return (baserowz* i)). "baserow*" is an array which contains links to "node" items, not…

or abuse, ouch!

   (unless (setq znode (tellz l node))
     (return t))
Post reply on HN