Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Happens When You Mix Java with a 1960 IBM Mainframe

thenewstack.io

Post reply on HN
Print view View original

51–60 of 84 posts

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

#51

Post by lokedhs »

sillysaurus3 wrote: post #44
Animats wrote: post #28

I'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)) That ought to be simple enough. But it's being applied not to a list, but a "hunk". A "hunk" is an obsolete MacLI…

There are only a few possibilities for what (cadr hunk) could mean. One way to solve this is to try them all and see which one runs successfully. Based on †, it sounds like (cadr (hunk (hunk 1 2) 3)) should return 2. Is the old LISP code available online somewhere? I'm curious to see it.

You can run it on an emulated PDP-10 running ITS. A friend of mine has been creating an easy-to-use project setting all of this up. MacLisp is included in the the system.

https://github.com/PDP-10/its

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

#53

Post by geodel »

electrum wrote: post #46
geodel wrote: post #36

Earlier quoted context omitted.

I am inclined to say Java as I have not seen mythical teams who work on Java without whole caboodle of 'Enterprise Apps' culture.

You can write modern software on Java without using "enterprise" features: https://github.com/prestodb/presto

Nice. It may be the best way to organize project this large. I know this is maven thing and once using everyone's favorite Intellij IDEA it should not matter but I personally find ~1000 directories for ~4000 files a kind of Javasim.

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

#54

Post by sillysaurus3 »

Animats wrote: post #47
sillysaurus3 wrote: post #44

Earlier quoted context omitted.

There are only a few possibilities for what (cadr hunk) could mean. One way to solve this is to try them all and see which one runs successfully. Based on †, it sounds like (cadr (hunk (hunk 1 2) 3)) should return 2. Is the old LISP code available online somewhere? I'm curious to see it.

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 structure looks like

  (list (list '(1 . 1) node))
Assuming "node" is an enode, the way to access it would be (cadar znode), not (cdar znode). Try changing the definition of getenode to

  (defun getenode (l) (cadar l))
and see if it runs.

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

#55

Post by lokedhs »

walrus01 wrote: post #13

When 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).

Being someone who worked for Sun at the time, I'd rather say it was Scott McNealy's dream.

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

#56

Post by bsg75 »

electrum wrote: post #46
geodel wrote: post #36

Earlier quoted context omitted.

I am inclined to say Java as I have not seen mythical teams who work on Java without whole caboodle of 'Enterprise Apps' culture.

You can write modern software on Java without using "enterprise" features: https://github.com/prestodb/presto

Can you expand on what makes the Presto project different than the aforementioned enterprise approach? (Not a Java developer, so I don't have context)

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

#57

Post by mbellotti »

benballjr wrote: post #32
mbellotti wrote: post #18

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

Hi Marianne! I'm with The New Stack (not the writer of this article), and was wondering about the video myself. Interesting to see you address that there's definitely no public facing version, as it seems a lot of the commenters here would love to see it. I can only imagine the bureaucrat complexity involved.

Oh yeah, when I talked to the agency that owns the 7074 (more on this in a second) they were like "You can't do this because we will get hacked"

"How are you going to get hacked if I talk about your mainframe? It's not connected to the public internet, is it?"

"No. Well... we don't know... but ... hackers! Hackers are really smart Marianne."

Part of the compromise was that I promised I would only use information that was already available publicly through government reports and news articles. I went back through my talk and documented where each fact was already published somewhere else until they were comfortable with it. So the ambiguity on whether the 7074 was the actual machine or an emulator was deliberate... there were certain things I could not find a public comment on and therefore agreed to avoid making direct statements about.

This all seems super annoying, but it makes sense when you realize how heavily scrutinized public servants are. In the end they are only trying to protect me, my organization and Obama's legacy. Three things that are really important to me. So I can't exactly blame them for it. I was happy to be able to find a middle ground where they felt comfortable, the organizers weren't too badly inconvenienced and I got to give the talk I wanted to.

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

#58

Post by mbellotti »

mtdewcmu wrote: post #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...

This is the one thing the article got wrong about the talk. The 7074 replaced magnetic drums with core memory. It's an easy mistake to make since the 700 series used vacuum tube logic and the 7070 replaced those with transistors. The 7074 came about two years after that.

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

#59

Post by dbremner »

Animats wrote: post #28

I'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)) That ought to be simple enough. But it's being applied not to a list, but a "hunk". A "hunk" is an obsolete MacLI…

Is http://maclisp.info/pitmanual/hunks.html helpful?

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

#60

Post by wahern »

andai wrote: post #40
wahern wrote: post #35

Earlier quoted context omitted.

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.

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 64-bit hardware even came into being.

Some (or all?) of the latest Unisys mainframes run on Intel Xeons, but with custom chips for translating the machine code of their old architectures.

I don't work in this area. I just like reading about it. Though, unfortunately, it's difficult to find clear specifications and descriptions on how these architectures work.

For example, Unisys' 2200 ClearPath architecture is one of the (if not _the_) last architectures still sold that uses signed-magnitude representation, as well as having an odd-sized integer width of 39 bits. (INT_MAX is 549755813887 and INT_MIN is -549755813887, and the compiler has to "emulate" the modulo arithmetic semantics required of unsigned types in C. ClearPath MCP is also a POSIX system, and has to emulate an 8-bit char type.) I discovered that you could download the specification for their C compiler for free online, which was useful when discussing the relevancy of undefined behavior in C. But AFAIU (and this is where finding concrete details is more difficult) the latest models of the ClearPath line use Xeons with custom chips bolted on to help run the machine code of the older architecture. In any event, the point is that while the old architecture is arguably emulated, it's not a pure software emulation that you might assume, and the resulting performance is better than the previous models of those mainframes, which were still being built at least until a few years ago. In other words, direct memory access isn't ruled out because the I/O systems may have been intentionally designed to work efficiently in a backwards compatible manner.

Post reply on HN