I’ve often mentioned that one of the key, foundational strengths of the IBM mainframe is its support for “old” program code for as long as that code still has business value to the organization that runs it. With rare exceptions, you don’t have to throw away your perfectly useful, well-functioning, well-integrated, costly-to-create (or recreate) code just because IBM or some other vendor decides the technology ought to be obsolete for whatever parochial reasons they have. That 1964 hallmark commitment to backward compatibility is practically sacred because that’s what makes sense for business. That doesn’t mean you should or must run every program written decades ago, but it means you can when it makes sense. Good stuff — though often misunderstood and occasionally abused (in business terms).

In that spirit, let’s see if you, our loyal readers, can come up with the best answers to the following questions about the “oldest” software. “Oldest” has many possible definitions. See if you can identify the following pieces of software and their years (or approximate years) they were born (or last modified):

1. Oldest program of any kind in any medium that’s still running today.

2. Oldest program still running on an electromechanical computer.

3. Oldest program still running on z/OS. (Hint: Likely an in-house application, and likely born pre-System/360, i.e. before 1965.)

4. Oldest program included within z/OS 2.1. (That is, the program module within z/OS unmodified for the longest period of time.)

5. Oldest vendor program for z/OS still marketed. (In this case “oldest” will be somewhat arbitrarily defined as longest period of time without a change in either the version or release number, or vendor equivalent. “Marketed” is tricky, but let’s set some boundaries: the program must be listed on a vendor’s Web site, the vendor must still be answering their phone, and a non-absurd price quotation is obtainable.)

6. Oldest IBM program for z/OS still marketed. (Same “oldest” and “marketed” as #5.)

7. Oldest vendor program for z/OS still supported. (Same “oldest” as #5. May or may not be the same answer as #5.)

8. Oldest IBM program for z/OS still supported. (Same “oldest” as #5. May or may not be the same answer as #6.)

9. As a bonus, the oldest model mainframe hardware still in productive end-user service (i.e. not in a museum or equivalent).

The floor is open, and nominations are now being accepted in the comments. Good luck!

5 thoughts on ““Oldest” Software Contest

  1. I left IBM a long time ago, but at the time there was a pile of Select360 code being run (I actually saw a copy of a copy of a copy of the line printer printed manual which described it as a port of select1410. I bet it would not be hard to find this code still running inside IBM. There was a project to re-write all of the code (millions of dollars at the time) in IMS or something (don’t recall the project details) until somsone looked at the code and found that they could port it to XA architecture by changing six lines of code in the select360 executable.

    That would be my nomination if anyone can find traces of it, as it technically goes back to the 1401/1410.

    Reply
  2. Pingback: "Oldest" Software Contest: First Follow-Up - Millennial Mainframer

  3. I can’t beat John’s 1401 example, but the do-nothing/return RC 0 IEFBR14 used for pretty much all file creation/deletion on a default install over the past 40+ years is definitely up there. It’s also probably the most-run application of its vintage in the world when you think about how often it gets invoked across all the different vintages of mainframes globally for basic file I/O.

    http://en.wikipedia.org/wiki/IEFBR14

    Reply
  4. I would have to say in response to item #4, that IEFBR14 is the oldest program included within z/OS 2.1 (the program module within z/OS unmodified for the longest period of time). I recall it being present when I was working with OS/360-MVT in the early 70s. It also existed in OS/VS1-SVS and OS/VS2-MVS.

    There are reports that the initial version failed to set the return code to 0 and it is my recollection that was correct based on random, non-zero return codes from a step which ran IEFBR14. Normally, that wasn’t a problem since it was used as part of single step “utility” job to create or delete datasets via JCL DD statements. However, the non-zero return code would be a problem if the job included other steps that specified COND=(0,NE) on the EXEC statement.

    Reply
  5. This doesn’t quite compete with 1401/1410 code — but when I worked in POK OS/360 System Design Department 1968-71, I came across IEFSD095, the block letter formatter for job separator pages. It was such butt-ugly code that I rewrote it. Of course, I hadn’t been assigned to do that — I just couldn’t resist. Then I wrote a test driver to run it a thousand/million/billion/? times to see how much faster my code was than the original. The answer: much. Of course, my MUCH faster code replaced code which was a vanishingly small part of job overhead. Equally of course, I couldn’t get my version integrated/shipped because (I was told) it was too much trouble to regression test it for problems. Implicit, of course, was the thought, “Who cares?”. I recently mentioned on IBM-Main this episode and someone checked, responded, “Still there, still ugly”. So it might go back to OS/360 early development days, pre-1964.

    Reply

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

required