Standing on the shoulders of giant mistakes

Anyone who has never made a mistake has never tried anything new

In some posts I have pointed out other’s blunders. When I see a mistake on system level design I try to remember it, so I do not have to repeat. One such example is return codes. Return codes are numeric values used to signal the outcome of a piece of code e.g. a function. Traditionally return code 0 (zero) means all went well and the higher return code code the less well the piece of code was able to perform. The problem with such return codes, the more values they have the more complex will the interface be, since the receiver of the return code must be able to deal with all values, as long a function is called from one caller only this is not that bad, but when a function is called from several callers this starts to get messy and when the return code scheme is changed it is common not all callers are updated to handle the new or changed return code values, which in the end will trigger erratic behavior. I try to use only two values as return code, 0 (zero) indicate failure, non-zero indicate success. Almost all modern programming languages supports Boolean true/false values and zero is decoded as false while non-zero is true, and I abide by these languages, breaking with tradition making zero signal failure instead of success. This makes my programs simpler and less error prone. I have to translate return codes when calling or being called from external software. Knowing I’m right makes that extra work light. There are situations where the true/false return code values are not enough, one example is the absence of a return code, a null value.    

In IBM’s Job Control Language (JCL) condition codes are return codes signal the outcome of a jobstep. E.g. step 1 in a job ends with condition code 4, step 2 tests for a 0 (zero) condition code which in this case means it will not execute. Now step 3 tests for a 0 (zero) condition code from step 2, which means step 3 expects step 2 run successfully. But in this example step 2 didn’t run, so JCL sets a default 0 (zero) condition code. In JCL a successful execution or no execution at all are both flagged by a 0 (zero) condition code. 

In my job control language ITL, I tackle this problem, allowing to test for bumped over job(steps) plus give an option how to interpret bumped over jobs (success or failure). I consider my ITL language’s return code scheme better than any other job control system I have have seen. This is not because I am better, but because I have had the chance of learning from other’s mistakes.
If you study my works you can learn a lot.