Linked by Thom Holwerda on Mon 26th May 2014 21:24 UTC
In the News

It's hard to explain to regular people how much technology barely works, how much the infrastructure of our lives is held together by the IT equivalent of baling wire.

Computers, and computing, are broken.

Software sucks. It really, really sucks. I have yet to meet a piece of software that didn't make me go "...eh." several times per hour - whether it be a videogame, a browser, or an operating system.

Thread beginning with comment 589589
To read all comments associated with this story, please click here.
Heck, even the "NULL" program is broken
by softdrat on Tue 27th May 2014 02:19 UTC
softdrat
Member since:
2008-09-17

Long ago I ran the program IEFBR14. Ran it many times. This program did absolutely NOTHING - it's sole purpose was return control to the operating system.

The program was 2 bytes long. Return control to the OS. One simple machine instruction. Absolutely nothing could go wrong. Right?

It had a bug.

http://catless.ncl.ac.uk/Risks/6.14.html#subj1

Reply Score: 3

Doc Pain Member since:
2006-10-08

Long ago I ran the program IEFBR14. Ran it many times. This program did absolutely NOTHING - it's sole purpose was return control to the operating system.


The reason why it existed was to satisfy the requirements of valid JCL: Every job deck had to have at least one EXEC statement to be considered valid (JOB card, EXEC card, optional // card). IEFBR14 was there to provide this program that could be EXECuted. A nice side effect was to use this program to issue file (correct: "dataset") dispositions without actually needing any "processing" program that did things with them, to manipule the file catalog or to build libraries (later obsoleted by dedicated programs). It could also be used to alter the job flow because the return code could be evaluated in later job steps with the COND= parameter. It could also serve to "tidy up" after the last job step, eliminating unused or "accidentally" kept files). Finally, it could be used to make sure, when being used in the first job step, that following steps would be able to allocate sufficient storage capacity (and if not, let the job fail early).

This is just another illustration of how broken things were - when the null program actually had several useful purposes. Having written this, I feel old now. I should run IEFBR15. ;-)

Reply Parent Score: 3