"Characters", "Display", "Zoned-Decimal" is stuff that we humans can read on a display (with no HEX capabilities) or on a printed line.
However, the CPU can't directly do calculations with such things. All CPUs like binary for calculations. 360/370 (and I have no idea at all what other architectures) also support calculations and manipulations of "packed-decimal" values. If you are adding up a list of order values that start off as "display", then you will convert them to packed decimal, do the addition, and convert the result back to display at some point for a user to see. On IBM, you don't have to convert to binary, unless you are naturally using binary.
Your SUM is an 80 character field. Could be a punch card, an old console-type printer, an 80x40 display or whatever, but for anyone to be able to see what the sum is, you have to unpack the calculated total. To do the calculation, all the components have to be in "packed" format.
The OR with "F0" stuff is to make sure that any sign is not carried forward from the calculation (Cx or Dx). Because the result of just allowing the display of the positive or negative in the low-order byte is that the low-order byte can no longer be read by humans when displayed/printed.
All this stuff is what you will be doing lots of if you are using Assembler for "application programming" tasks. Hopefully you'll get lucky, and you can get a higher-level language to do all that work for you, but it is useful to know what Cobol, for instance, is going through when you do an ADD or COMPUTE or whatever. Generate the Assembler code on your Cobol listing and you'll see the same sort of stuff as this example.