gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] [Bulk] Posible difference in the precision of COMP


From: Rich Smrcina
Subject: Re: [open-cobol-list] [Bulk] Posible difference in the precision of COMPUTE statements between OPEN COBOL 1.1 and mainframe COBOL
Date: Fri, 26 Feb 2010 08:46:12 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

The term mainframe is not ambiguous. Mainframe refers to the IBM System 360/370/390/z/System z class of computer systems. Other systems that call themselves 'mainframes' are hopping on the bandwagon, and likely do not use the same architecture or have the same reliability and availability characteristics.

On 02/26/2010 08:25 AM, Mark Perew wrote:
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 <mailto: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
    <mailto: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
    <mailto: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


--
Rich Smrcina
Phone: 414-491-6001
http://www.linkedin.com/in/richsmrcina

Catch the WAVV! http://www.wavv.org
WAVV 2010 - Apr 9-13, 2010 Covington, KY


reply via email to

[Prev in Thread] Current Thread [Next in Thread]