Frankly, I didn't think it through. I was confusing arithmetic operations (ADD, SUBRACT, MULTIPLY, DIVIDE, COMPUTE) with the MOVE statement.
"MOVE +99990000 TO PIC-V9999" would unconditionally result in ZERO. MOVE silently "beheads" high-order digits and truncates low-order digits as needed to fit the destination.
What "COMPUTE PIC-V9999 = +99990000" would do is dependent on whether the COMPUTE includes a ROUNDED phrase, what that phrase is, whether testing for the appropriate COBOL exception conditions are enabled, and whether an ON SIZE ERROR phrase is specified by the COMPUTE. If the ROUNDED phrase is not specified, the default is ZERO because the default mode absent the phrase is TRUNCATION (toward zero). For at least some of the other explicit ROUNDED modes, I would expect a fatal COBOL exception condition. The language implementor chooses whether execution continues after such a fatal exception condition is detected, and the results in the destination are also defined by the language implementor if execution is continued.
The historical ROUNDED mode -- if the phrase is specified -- is NEAREST-AWAY-FROM-ZERO. For the other sample case -- "COMPUTE AN-INTEGER = 0.0099 ROUNDED", as far as COBOL's going to round is one digit, leading to an intermediate result of "0.0100". Again, I'd expect a fatal exception for this case if no SIZE ERROR is specified, and I'd expect a zero result if no ROUNDED phrase is specified.
> Date: Sun, 22 Jan 2012 21:53:43 -0500
> To: stds-754@xxxxxxxxxxxxxxxxx
> From: hack@xxxxxxxxxxxxxx
> Subject: IEEE rounding and COBOL
> On Tue, 29 Mar 2011 10:11:05 -0600 Chuck Stevens wrote:
> > For fixed-point arithmetic, COBOL has always operated under what I
> > will call the "window of significance" principle. For example, if the
> > intermediate result of an operation is +99990000 (= +9.9990000...e+7),
> > and the receiving field is described as having five decimal digits with
> > the implied decimal point on the left (PICTURE V9999 USAGE DISPLAY),
> > the result is ZERO, regardless of any rounding specification, ...
> I'm a bit confused by the example value cited. It seems to me that ANY
> exact integer would be displayed as .0000 because the format explicitly
> beheads the integral part.
> > As I see it, for strict conformance to IEEE rules, the overflow exception
> > would be raised for all rounding modes.
> Only if COBOL claims that this PICTURE format corresponds to one of the
> conversions described by Clause 5.12.2 of 754-2008. Nothing prevents COBOL
> from having conversions that play by their own rules. What 754 *does*
> require is that there be *some* operation that converts floating-point
> datums (as we call them, deliberately) to decimal character strings that
> obey the 5.12.2 rules. If COBOL has a format that allows an exponent to
> be displayed this should not be a problem -- especially if those formats
> are allowed to raise exceptions (which are indeed permitted to be fatal).
> > But it seems to me that at least some of the IEEE rounding-direction
> > attributes would produce a value of +(0.)9999.
> Not in this case, as this is effectively an EXACT overflow, possible if
> overflow is trapped. If a trap handler other than termination is available
> the beheaded part (or the original source value) should be made available
> to it. Rounding applies to lost low-order bits or digits, not to beheading.
> > Similarly, when the intermediate result is like +0.0099 (= +9.9e-4) and
> > the receiving field is a four-digit integer (PIC 9999 USAGE DISPLAY),
> > the result historically expected from COBOL is ZERO, with no exception
> > condition raised, and regardless of the presence of the ROUNDED phrase
> > (or any specification of modes of rounding).
> This case is different. Here rounding is applied, and if directed rounding
> away from zero is in effect (and that PICTURE format claims to be one that
> follows 754-2008), then the result would have to be 0001.
> Directed rounding is easy to understand: the result must be no greater than
> (or no less than) the exact value, and be the nearest with that property.
> ---Sent: 2012-01-23 03:19:38 UTC