Some more thoughts on this basic topic:
In the standard (still) under development, COBOL has two stipulated contexts in which rounding occurs.
"Intermediate rounding" predicates are applied, when necessary, in the conversion of data into the intermediate form for the program (Binary128, Decimal128 BID, or Decimal128 DPD). It applies for any case in which the datum is not already in exactly the intermediate form.
"Intermediate rounding" predicates also apply during the application of arithmetic operations.
Thus, "intermediate rounding" applies everywhere in arithmetic operations UP TO, but NOT INCLUDING, the conversion of the intermediate result for storing in receiving fields. That mode is separately appied by the "DEFAULT ROUNDED MODE" and "ROUNDED MODE" clauses, during that conversion and storing process.
COBOL generally ignores the "inexact" exception; this can be "trapped" by specifying "INTERMEDIATE ROUNDING IS PROHIBITED" and/or "[DEFAULT] ROUNDED MODE IS PROHIBITED". I do not expect this feature to enjoy wide use in production, but I do think it would be useful in testing of critical environments. And when the ROUNDED phrase is NOT specified for an arithmetic operation, and the result is inexact, trailing digits are truncated (thus, roundTowardZero applies by default).
All of IEEE 60559's directed rounding modes are provided for in these two basic contexts, plus some others requested for compatibility with other languages.
The followiing qualifiers are available in the draft standard with both the "ROUNDED MODE" phrase for individual arithmetic statements and for the "INTERMEDIATE ROUNDING" clause on a program-wide basis:
AWAY-FROM-ZERO (for positive values, ISO 60559 "roundTowardPositive"; for negative values, ISO 60559 "roundTowardNegatative)
Furthermore, the user is also allowed to specify any of these in the "DEFAULT ROUNDED MODE" clause on a program-wide basis, allowing the user to override what happens when the ROUNDED clause IS coded WITHOUT any specification, and also allowing the user to override THAT chosen default for the program for any given statement within that program.
The historical default result WITHOUT a ROUNDED phrase is "roundTowardZero", which remains the case in the draft; the default WITH a ROUNDED phrase and WITHOUT a DEFAULT ROUNDED MODE" clause remains "roundTiesToAway" as before.
As COBOL is fundamentally a decimal-based language, I would not expect any surprises in conversion of data already in decimal form when ARITHMETIC IS STANDARD-DECIMAL is specified; that tells the compiler that the rules for a Decimal128 intermediate form apply. (DPD and BID are selectable for user data, but it's up to the implementor which one he chooses for the intermediate form).
Issues of inexactness -- and thus of rounding -- are encountered when ARITHMETIC IS STANDARD-BINARY is specified (rules for Binary128). Conversion of fixed-point noninteger decimal data into Binary128 format (or any other binary floating-point format with a base-2 exponent, for that matter) is frequently inexact -- the most obvious example is the decimal value "0.1" which can't be represented exactly in such a format; the significand is a repeating sequence of digits.
Inexactness can also occur for noninteger fixed-point binary operands in conversion to Decimal128.
> 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