Add to zero...What is it for?

Why such code is used in some applications instead of a MOVE?

     add 16 to ZERO giving SOME-RESULT

Without seeing more of the code, it appears that it could be a translation of IBM Assembler to COBOL. In particular, the ZAP (Zero and Add Packed) instruction may be literally translated to the above instruction, particularly if SOME-RESULT is COMP-3. Thus, someone checking the translation could see that the ZAP instruction was faithfully translated.

Or, it could be an assembler programmer's idea of a joke.

Having seen the code, I also note the use of

    subtract some-data-item from some-data-item

which is used instead of

    move zero to some-data-item

This is consistent with operations used with packed decimal fields in IBM Assembly, where there are no other instructions to accomplish "flexible" moves. By flexible, I mean that the packed decimal instructions contain a length field so that specific size MVC instructions need not be used.

This particular style, being unusual, may be related to catching copyright violations.

From my experience, I'm pretty sure I know the reason why the programmer would have done this. It has something to do with the binary representation of the number.

I bet SOME-RESULT is a packed-decimal (or COMP-3) format number. Let's assume the field is defined like this

05 SOME-RESULT          PIC S9(5) COMP-3.

This results in a 3-byte field with a hex representation like this

x'00016C'

The decimal number is encoded as a binary encoded decimal (BCD, one decimal digit per half-byte), and the last half-byte holds the sign.

Let's take a look at how the sign is defined:

• if it is one of x'C', x'A', x'F', x'E' (café), then the number is positive
• if it is one of x'B', x'D', then the number is negative
• any of x'0'..'x'9' are not valid signs, so we can distinguish signed packed-decimals from unsigned.

However, a zoned number (PIC 9(5) DISPLAY) - as in the source code - looks like this:

x'F0F0F0F1F6'

As you can see, each decimal digit is an EBCDIC character with the 'zone' part (the first half-byte) always being x'F'.

Now we get closer to your question!

What happens when we use

MOVE 16 TO SOME-RESULT

If you just MOVE a number to such a field, this results in being compiled into a PACK instruction on the machine code level.

PACK   SOME-RESULT,=C'16'

A pack instruction takes a zoned number and packs it by picking only the second half-byte of each byte and storing it in the half-bytes of the packed number - with one exception! When it comes to the last byte, it simply flips the two half-bytes and stores them in the last half-byte of the decimal.

This means that the zone of the last byte of the zoned decimal becomes the sign in the packed decimal:

x'00016F'

So now we have an x'F' as the sign – which is a valid positive sign.

However, what happens if use this Cobol instruction instead

ADD 16 TO ZERO GIVING SOME-RESULT

This compiles into multiple machine level instructions

PACK   SOME_RESULT,=C'0'
PACK   TEMP,=C'16'
AP     SOME_RESULT,TEMP

(or similar - the key point is that is needs an AP somewhere)

This makes a slight difference in the result, because the AP (add packed) instruction always sets the resulting sign to either x'C' for a positive or x'D' for a negative result.

So the difference lies in the sign

x'00016C'

Finally, the question is why would one make this difference? After all, both x'F' and x'C' are valid positive signs. So why care?

There is one situation when this slight difference can cause big problems: When the packed decimal is part of an index key, then we would not get a match, even though the numbers are semantically identical!

Because this situation occurred quite often in older databases like VSAM and DL/I (later: IMS/DB), it became good practice to "normalize" packed decimals if they were part of an index key.

However, some programmers adopted the practice without knowing why, so you may come across code that uses this "normalization" even though the data are not used for index keys.

You might also wonder why a compiler does not optimize out the ADD 16 TO ZERO. I'm pretty sure it once did, but that broke a lot of applications, so this specific optimization was removed again or at least made a non-default option with warnings.

Additional useful info

Note that at least the Enterprise Cobol for z/OS compiler allows you to see exactly the machine code that is produced from your source code if use the LIST compile option (see this example output). I recommend to always compile with options LIST, MAP, OFFSET, XREF because these options enable you find the exact problem in your Cobol source even when you only have a program dump from an abend.

Anyway, good programming practice is not to care about the compiler or the machine code, but about the other programmers who will have to maintain, and thus read and understand the code. Good practice would be to always prefer simple and readable instructions, and to document the reasons (right in the code) when deviating from this rule.

Some programmers like to do things "just because they can". I have a feeling that is what you are seeing here. It makes about as much sense as doing

a := 0 + b

would in go.