What Is the Oldest Code Written Still Running?
Consul writes "What is the oldest piece of code that is still in use today, that has not actually been retyped or reimplemented in some way? By 'piece of code,' I'm of course referring to a complete algorithm, and not just a single line." The question would have a different answer if emulation, in multiple layers, is allowed.
One of the original IBM System S360 programs, IEFBR14 is still in wide use today. IEFBR14 CSECT SR 15,15 BR 14 END Only two changes in over 40 years. It doesn't do much, in fact nothing except set a zero return code, but it is widely used for dataset allocation purposes in batch dataset allocation processing.
Once they rebuilt the Manchester Mk. 1 ten years ago, Alan Turing's program became the oldest program runnable without emulation. It clocks in at 60 years old, being written in 1948. The code finds the highest common factor between any two integers expressable in 32 bits. Not bad, given that the Mk. 1 had only one arithmetic operator, subtract.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
If by "program" you mean a stored program on what is conventionally meant by a computer today, I have a candidate. IEFBR14 was used on the earliest version of OS/360 in 1964 as a do-nothing program. It is still in use today, unchanged on the latest version of z/OS. Its function is to execute a JCL step which does nothing, but in the process of doing nothing, the job scheduler is invoked. This is one method of creating and deleting datasets (files). It is also the shortest valid OS/360 (and z/OS) program, containing two executable assembler statements and two assembler directives. The comments are mine.
IEFBR14 CSECT START PROGRAM SECTION
SR 15,15 SET EXIT CODE TO 0
BR 14 RETURN AND EXIT
END TELL ASSEMBLER END OF PROGRAM
Interestingly, the first version of this program had a bug, which was subsequently corrected by doubling the program length. It omitted the SR 15,15 statement, which meant that at program exit register 15 had an unpredictable value -- and the program exit code was therefore unpredictable. Since a zero exit code is used to guide the conditional execution of subsequent steps, a failure could be indicated when there was none.
And contrary to another post, I believe there are a lot of people with computer experience predating 1970 who read Slashdot. But I don't want to start a flame war over that.
Just a few weeks ago, one of my guys was looking at an old system that we have running. It is an old IMS application running on an IBM mainframe used to manage some factory equipment. We want to replace that system (even though "it just works"), so my guy was looking into it to see how it worked, as documentation is, of course, non-existent.
The source code was written by my first CIO in the mid 1980s (who retired in the early 1990s), and it had a comment at the top which stated that it was created in January, 1968. It is quite sloppy... clearly before anyone thought about writing pretty code. There is no doubt in my mind that it was originally written on coding forms, and subsequently loaded into a machine via the long-defunct keypunch department. The program, of course, is running on much newer hardware now, but the code that is running was written in 1968.
I speculate that there is a bunch of older code outside of my company.
Yes there are. The carpet-weaving industry in the UK still uses card-programmed looms (I have a friend who is employed to load card decks into the machines).
>If there was a power outage, they might not be able to find the guy to turn on the machine? Then it's time to upgrade.
:)
:)
If it's a mission-critical system, then power outages aren't a concern: The system itself will have a UPS capable of keeping the system running for quite awhile once main power drops, and also will have a generator of some sort backing that up as well. It starts up after a specified amount of time, far in advance of when the UPS will fail.
Once mains power drops, and the UPS starts, alerts are generated to those responsible for keeping the system running, and one of the first things that those people will do is call the company that provides their electricity to ascertain the nature of the outage.
From there, they will arrange for additional fuel for the generator, should the outage be prolonged, and most likely will already have such arrangements in place, if they are doing their jobs properly. In addition, they will start alerting the people in charge of the department(s) that rely upon it, and will keep them informed as well, so that they can plan for it being shut down, should such be required.
However, for the most critical systems, plans will be in place for a transfer of services off-site, should such be necessary.
And, again, if it's mission-critical, regardless of its age - all of these things have been planned for, years since, and, if done properly, they are tested on a regular basis as well: Contracts are in place, points of contact as well, and all are updated regularly: Part and parcel of keeping the system running.
And trust me, if all else fails, and it needs to be shut down, then such has been planned for as well, including having "a guy" available to turn it back on, once reliable power is available.
In addition, such things as handling "what happens if it breaks" have also been planned for, and that includes migrating, when such is deemed necessary.
I'm not sure why you got modded up to +5 Insightful, since there's nothing really insightful at all about your post: It reeks of assumptions that simply do not apply in the real world for those of us in IT that actually support mission-critical systems daily, and do so with an eye towards service and availability for those that rely upon them.
But, this *is* Slashdot: Many here think that those of us in IT exist only to thwart them, because we are clueless, and afraid of their superior "skillz", by their estimation.
I trust I've proven that such isn't always the case
Captcha: archfool
That made me laugh - it's an amazingly appropriate summation of my opinion of the parent poster
And I say that with NO anger. If anything, I'm saddened that such a post was found to be insightful by anyone.
is there actually a joke in there?
The joke is that not only it takes four lines of unintellegible gibberish to do with JCL what we would today write as 'rm my/file/name', but also that, against all odds (and all that is holy), it still works today and is used in the exact same way it was used when somebody's grandfather first wrote it.