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

71–80 of 84 posts

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

#71

Post by larsbrinkhoff »

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…

You should consult the Maclisp manuals. There is one in ITS, and the Pitmanual is here: http://maclisp.info/pitmanual/index.html

You should probably also test some code in Maclisp.

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

#72

Post by kpil »

tomcam wrote: post #68
1812Overture wrote: post #24

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

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

I think most of it is highly unlikely...

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

#73

Post by [deleted] »

tomcam wrote: post #68
1812Overture wrote: post #24

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

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

[deleted]

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

#75

Post by vidarh »

YeGoblynQueenne wrote: post #17
skissane wrote: 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…

PDP-10 was discontinued in 1983, but PDP-11 wasn't discontinued until 1997, with third-parties continuing to sell parts, so it's really not that unlikely to come across PDPs, depending on which line.

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

#76

Post by junke »

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…

Note that this is the order of display:

The order of display of hunk slots is historical in nature. For better or worse, the elements of a hunk display in order except that the 0th element is last, not first. e.g., for a hunk of a length n+1, (cxr1 . cxr2 . ... . cxrn . cxr0 .)

It could still make sense to have the layout in memory being sequential, like (cxr-0 == CDR, cxr-1 == CAR, ...others ...).

Note also that CAR extracts the leftmost element of a hunk, just as it addresses the leftmost element of a cons. Similarly, CDR extracts the rightmost element of hunks and conses.

It seems more logical that CADR is just the combination of CAR with CDR. It don't think the designers would try to transpose the fact that it means "second", with proper lists, for hunks. It just seems unlikely, but I have no proof.

Also:

(Note that the operation CAR is undefined on hunk-1's, but CDR is not.) This means that if you want to make a plist for a hunk of your own, you can use its cdr as a hunk; it does not mean that you can blindly assume that any hunk wants its CDR treated that way. The exact use of the slots of a hunk is up to the creator; it's a good idea to mark your hunks (e.g., by placing a distinctive object in their cxr-1 slot) so that you can tell them from hunks created by other programs.

My guess is that there is some metadata associated with a hunk, stored in CRX-0, a.k.a. CDR.

http://www.maclisp.info/pitmanual/hunks.html

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

#77

Post by dfox »

wahern wrote: post #60
andai wrote: 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…

The 128bit pointer intermediate code is used on what IBM calls "midrange systems" (ie. AS/400), not mainframes. IBM mainframes execute their machine code directly and the ISA is designed such that it allows for efficient virtualization since beginning and is extensible and backwards-compatible. Otherwise the IBM mainframe magic is in IO offload and truly immense memory bandwidth. On the other hand, Unisys systems use architecture that is significantly different from what today's programmer would expect, with completely different memory model originally implemented in hardware (which essentially combines the memory protection model implemented on AS/400 in software with lisp machine-style pointer tagging).

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

#78

Post by eru »

3n7r0pY wrote: post #7
eru wrote: post #5

Earlier quoted context omitted.

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

> The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware.

Oh, I was talking more about older ways to organize the data centre: batch vs timeshare processing.

https://en.wikipedia.org/wiki/Time-sharing

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

#79

Post by vidarh »

stefs wrote: post #23
YeGoblynQueenne wrote: post #6

Earlier 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

Yes, but good luck translating any sizeable chunk of code to a higher level language without a massive effort figuring out which things are discarded side-effects that can be ignored and which things are relied on later. I just spent a few hours last night massaging a C-translation from 6502 assembler. It's a tiny piece of code - ~3000 lines that'll probably shrink to ~2500 or so as I figure out which results are ignored (the original translation attempted to do a faithful 1-1 translation instruction by instruction, which leads to things like long sequences to handle basic multiplication etc.), but it takes ages, because it is not always obvious when it e.g. depends on the status flags set, and values keep being moved between registers etc. Now try doing that with a big piece of code.

There's a reason why people often resort to emulators.

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

#80

Post by acqq »

kevin_thibedeau wrote: post #38
skissane wrote: 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…

ClearPath Dorado still had a Univac on a chip until 2015. This is actual hardware, not just software emulation.

Yes. And they never accessed 1960 IBM Mainframe at all with their software. The title is probably intentionally misleading.

And the one they actually accessed and received query results in 6 milliseconds was introduced in 2008, not so old and slow:

https://www.app5.unisys.com/offerings/ClearPathConnection/st...

"Single image performance range of 300 MIPS at the entry level and maximum single image performance of approximately 5,700 MIPS (32 processor system)."

"An expanded memory subsystem supports larger memory capabilities and offers memory configurations that include the ability to expand up to 4GW per cell and up to 32GW for a maximum eight-cell system."

Post reply on HN