TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

What Happens When You Mix Java with a 1960 IBM Mainframe

230 pointsby 3n7r0pYover 8 years ago

17 comments

Animatsover 8 years ago
I&#x27;m still struggling with my own legacy code problem. I&#x27;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.<p>My current struggle is with one line of code:<p><pre><code> (defun getenode (l) (cadr l)) </code></pre> That ought to be simple enough. But it&#x27;s being applied not to a list, but a &quot;hunk&quot;. A &quot;hunk&quot; is an obsolete MacLISP concept.[1]. It&#x27;s a block of memory which has N contiguous LISP cells, each with two pointers. This is the memory object underlying structures and arrays in MacLISP. Macros were used to create the illusion of structure data objects, with hunks underneath. However, you could still access a &quot;hunk&quot; with car, cdr, cxr, etc.<p>I&#x27;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.<p>But which element of the structure does (cadr l), which usually means the same thing as &quot;(car (cdr l))&quot;, access? (cadr (list 0 1 2 4)) returns 1, so you&#x27;d think it would be field 1 of the structure. But no. It&#x27;s more complicated and depends on how hunks are laid out in memory.<p>The Franz LISP manual from 1983 [2] says <i>&quot;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†.&quot;</i> At footnote &quot;†&quot;, <i>&quot;In a hunk, the function cdr references the first element and car the second.&quot;</i> This is backwards from the way lists behave.<p>A blog posting from 2008 about MacLISP says <i>&quot;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).&quot;</i> Note that element 0 is at the end, which is even stranger. The documentation is silent about what &quot;cadr&quot; would do. Does it get element 2, or get element 0 and then apply &quot;car&quot; to it?<p>The original code [3] contains no relevant comments. I&#x27;m trying to figure out from the context what the original author, Greg Nelson, had in mind. He died in 2015.[4]<p>[1] <a href="http:&#x2F;&#x2F;www.mschaef.com&#x2F;blog&#x2F;tech&#x2F;lisp&#x2F;car-cdr.html" rel="nofollow">http:&#x2F;&#x2F;www.mschaef.com&#x2F;blog&#x2F;tech&#x2F;lisp&#x2F;car-cdr.html</a> [2] <a href="http:&#x2F;&#x2F;www.softwarepreservation.org&#x2F;projects&#x2F;LISP&#x2F;franz&#x2F;Franz_Lisp_July_1983.pdf" rel="nofollow">http:&#x2F;&#x2F;www.softwarepreservation.org&#x2F;projects&#x2F;LISP&#x2F;franz&#x2F;Fran...</a> [3] <a href="https:&#x2F;&#x2F;github.com&#x2F;John-Nagle&#x2F;pasv&#x2F;blob&#x2F;master&#x2F;src&#x2F;CPC4&#x2F;z.lisp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;John-Nagle&#x2F;pasv&#x2F;blob&#x2F;master&#x2F;src&#x2F;CPC4&#x2F;z.li...</a> [4] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Greg_Nelson_(computer_scientist)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Greg_Nelson_(computer_scientis...</a>
评论 #13467413 未加载
评论 #13467301 未加载
评论 #13469970 未加载
评论 #13469462 未加载
评论 #13468356 未加载
skissaneover 8 years ago
Is someone in the US government really still using an IBM 7074? Really? I&#x27;m shocked. How could that possibly be cost-effective?<p>Actually, this blog post makes the story clearer:<p><a href="http:&#x2F;&#x2F;nikhilism.com&#x2F;post&#x2F;2016&#x2F;systems-we-love&#x2F;" rel="nofollow">http:&#x2F;&#x2F;nikhilism.com&#x2F;post&#x2F;2016&#x2F;systems-we-love&#x2F;</a><p>It isn&#x27;t a physical IBM 7074.<p>When it came time to migrate from 7074 to S&#x2F;360, rather than rewriting their 7074 software, they just wrote a 7074 emulator for S&#x2F;360. And, it sounds like, they are still running their 7074 software, under their 7074 emulator, most likely on a recent z&#x2F;Architecture mainframe.<p>The article makes it sound like people still use &quot;1960s mainframes&quot; 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.<p>A lot of legacy, sure, but I think this article makes it sound even more legacy than it really is.
评论 #13466198 未加载
评论 #13465909 未加载
评论 #13466247 未加载
评论 #13465804 未加载
评论 #13465598 未加载
评论 #13466876 未加载
评论 #13465705 未加载
评论 #13467106 未加载
评论 #13468638 未加载
评论 #13465577 未加载
评论 #13467229 未加载
mbellottiover 8 years ago
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&#x27;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 the idea that I was going to talk about information that was already public, without naming agencies or projects and without going into detail beyond what was in a user manual and that this was not a security risk.
评论 #13466858 未加载
YeGoblynQueenneover 8 years ago
&gt;&gt; It was at this point that the seasoned data architects in the department began expressing their exasperation. “15 years ago, everybody was telling us ‘Get off the mainframe, get on AT&amp;T applications, build these thick clients. Mainframes are out.’ And now thick clients are out, and everybody’s moving to APIs and microservices, which basically are very similar to the thin client that a terminal uses to interact with a mainframe.”<p>A.k.a. &quot;Them as not knows their history are doomed to repeat it&quot;. But I suppose it&#x27;s more the case of business imperatives than real ignorance that drive this mad race to make new stuff that works worse than the old stuff only so we can then go back to the old stuff with a different name.<p>Btw, that lady is my new tech hero:<p><i>“The systems that I love are really the systems that other engineers hate,” Bellotti told the audience — “the messy, archaic, half chewing gum and duct tape systems that are sort of patched together.</i><p>&lt;3 &lt;3 &lt;3
评论 #13466123 未加载
评论 #13466128 未加载
jonnycowboyover 8 years ago
The 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&#x2F;O was often run through specialised co-processors (such as IBM&#x27;s channel processors) and the terminals could sometimes help too.<p>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&#x2F;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.
评论 #13465531 未加载
评论 #13465460 未加载
nlover 8 years ago
Did anyone read this and go &quot;hu&quot;?<p>There&#x27;s this whole thing about how they are getting data from mainframes where &quot;the data was being returned in between one and six milliseconds&quot;.<p>But then: &quot;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&quot;<p>But <i>then</i>: &quot;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.&quot;<p>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?
geodelover 8 years ago
I have heard from many of my friends about massive projects of &#x27;modernizing&#x27; 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.<p>I think, though without any proof, that overreliance of 100s of mixed quality libraries, combined with &#x27;best practices&#x27; of enterprise development and heavy application of design patterns creates a very large surface area for change. This makes reasonable translation of functionality to Java almost impossible.
评论 #13465878 未加载
walrus01over 8 years ago
When I first saw the Chromebook, my thought was that Larry Ellison&#x27;s 1998 dream of a network computer thin terminal had come true. It&#x27;s smarter than a true thin terminal, but everything lives in the cloud (err, butt).
评论 #13468054 未加载
评论 #13466808 未加载
mtdewcmuover 8 years ago
&quot;It used magnetic-core memory (instead of cathode ray tubes) according to Bellotti&quot;<p>I didn&#x27;t think magnetic-core memory and CRTs were interchangeable...
评论 #13467859 未加载
评论 #13468332 未加载
评论 #13467945 未加载
评论 #13467074 未加载
brokentoneover 8 years ago
I&#x27;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.<p>Interesting problems not terribly well described in the post, would love to read more.
评论 #13468840 未加载
wolf550eover 8 years ago
An explanation from &#x27;bcantrill about why the talk was not recorded: <a href="https:&#x2F;&#x2F;lobste.rs&#x2F;s&#x2F;q2xz14&#x2F;systems_we_love_videos&#x2F;comments&#x2F;if9yox#c_if9yox" rel="nofollow">https:&#x2F;&#x2F;lobste.rs&#x2F;s&#x2F;q2xz14&#x2F;systems_we_love_videos&#x2F;comments&#x2F;i...</a>
mleonhardover 8 years ago
She likes those crufty legacy systems only because she works with each one for a short time. If she had to work on one every day for years, she would hate it, too.
stevehiehnover 8 years ago
Hmm, interesting. My bet is that the Java devs were not great at implementing concurrency. But who knows.
评论 #13467161 未加载
altitudinousover 8 years ago
If it ain&#x27;t broken, don&#x27;t fix it.
chris_wotover 8 years ago
You get sued for violating copyright?
platzover 8 years ago
Remember COBOL.net !
asjoover 8 years ago
EBCDIC stacktraces!