Re: Bah!
On real computers the "SYNC RIGHT" gets automatically added because the mill expects that. You can override it of course, but it is scarcely worth the trouble unless really starved for memory/disk space or have single word fields with multiple short values packed in them (The UNIVAC 1100 family has a 36 bit word that can be chopped in a number of ways, so using Cobol's SYNC is often a waste of effort better spent in the Data Division where fewer runtime errors will be waiting to silently bite us, for example).
What makes COMP a 'currency type' is that it is a binary numeric representation with a *decimal* scale factor. This means that arithmetic works as long as you know how the language arithmetic operators/verbs do, and have a grasp of implied intermediate value field types. Screwing up DIVIDE is a different order of problem, nothing to do with the declared variable picture clauses.
COMP-? declarations are different beasts, retrofits that are implementation dependent. I well remember a newly hired boss giving me gyp about using report writer because "it doesn't handle packed decimal", until I pointed out that packed decimal was an IBM conceit and we were in the world of Univac, where report writer worked just fine.
I can do COMP-? discussions all day because I once made my money converting such fields for running on other hardware than they were originally intended (lots of contracts with people doing government work), and somewhere I have a Univac Cobol Supplemental manual, long out of print, that details all the bizarre COMP variants for working especially with IBM->UNIVAC conversions (tape formats being top of the list. IBM x-track, y-parity, that sort of thing).
And yes, a bunch of clever young things really did nerf Wall St bizzes plural in the early 90s by deploying float types to record and calculate currency amounts. It was quite the secret scandal.
Biting the hand that feeds IT
