In DOS the return codes of a process or program are called error levels. So a nonzero "error level" indicates an error and zero indicates no error.

Here is a Multics document on "Standard Error Handling Practice" from March 1969. Scroll down to the second page and find "by convention, zero is the code for normal completion". That indicates to me that by the time of Multics' it was already common practice in computing that 0 indicated success/normal for subroutines. In Multics of course there was a close affinity between the way subroutines worked and the way processes worked - so it was natural that processes used the same mechanism. From there: UNIX.

ecm brings up a good point, many programs and libraries I used in the DOS days for C (eg, Turbo C) return error numbers (or error codes or error levels, depending on the naming conventions of the provider.)

@ecm MS-DOS borrowed exit codes from Unix, though, it certainly wasn't the origin.

The VMS convention was a low-bit convention: set=success clear=failure. This allowed for arbitrary numbers of success/fail codes. The entire status was a structured value, which meant you could (assuming decently-written software) know whose error code it was.

@another-dave - and since VAX had a BLB (branch on low bit) (with variants for BLBS (set) and BLBC (clear)) that worked out very well!

Windows NT, IMO, boggled that up by providing a two-bit field in the status to indicate SUCCESS/INFORMATIONAL/WARNING/ERROR.

Meanwhile, that wasn't good enough for the people who wrote COM - part of the OS eventually! - which just had to use a (slightly) different format, requiring different interpretation for COM status vs Windows API status.

@davidbak - but VMS had the same. The low two bits were 'severity'; from memory (i.e., unverified) 00=WARN 01=SUCCESS 10=ERROR 11=INFO. It is still the case that the low bit discriminates between whether "worked" or "didn't work".

VMS was not just the one-bit convention, the severity field was the least significant 3 bits. "Success" codes were STS$K_SUCCESS (1) and STS$K_INFO (3) whilst the "error" codes were STS$K_WARNING (0), STS$K_ERROR (2) and STS$K_SEVERE (4, also known as STS$K_FATAL).

@Martin - ah, yes. 3 bits, not 2. Thanks.

@davidbak I very much appreciate your citing Multix and the link, and so far your comment is the most accurate in answering: "What's the origin of process return status 0 meaning success?" and I therefore encourage you to post this as an actual answer to my question.

@RichardT - thanks for suggesting it - done!

Dear Anonymous editor proposing edits to my question: Your proposed edits are those of a computer, an atomaton, but THIS is NOT StackOverflow: this is a place where our HUMANITY and PERSONAL INVOLVEMENT should not be removed. What, are you worried about disk space? You want a sterile environment where there's no life?

Comment 2 to Dear Anonymous editor; your proposal is exactly the kind of thing that, if imposed WILL drive me away from being a contributor to this site. I am NOT a computer myself and I don't want MY input to be reduced to something that is so damned sterile. Please don't drive me away. Please instead RETRACT your proposed edits and, perhaps, if you feel NECESSARY, propose something less gutting of the whole thing to something a computer would write. You know, more human. If YOUR style is enforced, I'll delete 100% of MY input and never come back.

To follow up on @dirkt, there's an unlimited number of ways to fail, but only one to succeed.

Since it's not always possible for a function to know if it's been successful, it's probably not precisely accurate to say that a nominal-return-value represents success so much as a lack of failure-information to report.

@Nat Agreed; that's why I rather liked that speculated answer I postulated in the question: "Nothing to report."