Re: [open-cobol-list] [Bulk] Posible difference in the precision of COMPUTE statements between OPEN COBOL 1.1 and mainframe COBOL

[Mark Perew]

The term "mainframe" is ambiguous.  I'm wondering if the OP can be more specific.

I tested this on my Unisys Clearpath MCP mainframe, and both COBOL74 and COBOL85 return the correct answer of 002177.71.

On Fri, Feb 26, 2010 at 8:03 AM, Vince Coen <address@hidden> wrote:

As you say no rounding just truncates eg 77.70  (assuming pic 9(6)v99  etc.

With rounded using above example should make it 77.71 ie round to nearest .5
so 77.704 (or .001 - .004 is .70 and .705 to .709 is .71 assuming 2 dec places
in the pic clause.

Compiler differences will occur with such things as a compute statement but
memory is saying it should only round for the final answer BUT you will get
differences depending on the pic dec places for all values used in such a
statement.  If it is an issue, then the only way around it is to use 1/2 temp
storage areas with one or more extra dec places and use 'rounded' on the final
statement converting a compute into it's basic forms eg add, multiply, divide
etc.

On mainframe compilers and (used to be Micro Focus) you can tell the compiler
how to behave with intermediate results regarding rounded. My personal view is
that only the final answer should be rounded but that does depend on the
application and system specs etc. For the the larger compute type statements
should use intermediate resultants with extra 3 dec places but this is not
always possible.

...
In the example shown all values start as 2 dec places so the only obvious
issue is what settings are used for the specific m/f compiler re intermediate
rounding etc. I suspect default,  none.

Vince

On Friday 26 Feb 2010, Brian Tiffin wrote:
> As far as I know   ROUNDED  is NEAREST-AWAY-FROM-ZERO, and I get a
>  calculator result of
>
> 2177.705416666666667  so isn't  .71 the proper round up?
>
> 002177.70 is the result for no ROUNDED clause, the default "rounding" being
> trunctation.  No?
>
> I'm looking at Annex C of the  July 2009 Draft.  I'm not 100% on these
>  specs, but I'd wager that OpenCOBOL is right on this one,  and it's the
>  other compiler that needs a beat down.  :)
>
> Cheers,
> Brian
>
> On February 25, 2010 12:27:04 pm Wolfgang Westphal wrote:
> > 01  RESULT-1 PIC 9(6).99.
> >     COMPUTE RESULT-1 ROUNDED = 46956.93 / 24 + 5308.00 / 24
> >     DISPLAY RESULT-1
> >
> > OPEN COBOL displays 002177.71
> > mainframe displays  002177.70
>
> ---------------------------------------------------------------------------
> --- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list