IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

COBOL variable is not getting rounded off


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
muthurajan.b

New User


Joined: 22 Jul 2011
Posts: 6
Location: India

PostPosted: Fri Jul 22, 2011 9:58 pm
Reply with quote

Hi All,

My problem is, the final output of the variable is not getting rounded off.
In the above discussion as dick scherrer said the final variable is declared as follows.

05 OUTPUT PIC S9(01)V9(04) PACKED-DECIMAL
05 AAA PIC S9(09)V99 PACKED-DECIMAL
05 BBB PIC S9(07)V99 PACKED-DECIMAL
05 CCC PIC S9(09)V99 PACKED-DECIMAL
05 DDD PIC S9(07)V99 PACKED-DECIMAL
05 EEE PIC S9(07)V99 PACKED-DECIMAL
05 FFF PIC S9(09)V99 PACKED-DECIMAL
05 AAA PIC S9(09)V99 PACKED-DECIMAL
05 GGG PIC S9(03)V9(04) PACKED-DECIMAL
05 HHH PIC S9(01)V9(04) PACKED-DECIMAL

We had seen how the variables declared. The below is formula


COMPUTE OUTPUT ROUNDED =
((((FFF - AAA)-
BBB - CCC -
DDD - EEE)
/
(FFF - AAA)) *
GGG) +
HHH
ON SIZE ERROR MOVE +0 TO OUTPUT
END-COMPUTE

Please find the values of the variables

AAA 19928.57
BBB 0
CCC 968.4
DDD 0
EEE 0
FFF 23999.25
GGG 0.0599
HHH 0

My problem is the output what the program writing in the file is 0.0456

But actually it should be 0.0457 because if i have output as 7 decimal places (in excel where i simulated this formula) i am getting 0.0456500.

Please some one help me in this issue.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Jul 22, 2011 10:47 pm
Reply with quote

muthurajan.b wrote:
[...]

My problem is the output what the program writing in the file is 0.0456

But actually it should be 0.0457 because if i have output as 7 decimal places (in excel where i simulated this formula) i am getting 0.0456500.

Please some one help me in this issue.


Suggest you work through the COMPUTE as Cobol would, then decide whether the instruction is working or not. Billions of billions of times it has worked, I doubt it would just up and pick on you.

You want the answer in Excel, put the code in Excel. You want it in Cobol, put it in Cobol. You want Excel to tell you the Cobol answer, then do the Excel calc as Cobol does.

Generate the pseudo assembler. Excel, calculator, pen-and-old-listing, your choice. If you do it right, you'll get the right answer.
Back to top
View user's profile Send private message
Craq Giegerich

Senior Member


Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA

PostPosted: Fri Jul 22, 2011 10:47 pm
Reply with quote

Microsoft is not the ultimate authority on calculations. Look at the documentation for the software you are using, in the case of COBOL you have to read about and understand intermediate result.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Jul 22, 2011 10:58 pm
Reply with quote

First, don't respond to a topic inactive for over FOUR YEARS with a new question -- start your own topic. I split this off since it is a new topic.

Second, you cannot compare results from Excel and COBOL directly since they do not do calculations in the same way. You cannot even compare results from COBOL programs running on different platforms as they may use different rules for calculating intermediate results and hence may get different final results.

Third, click on the Manuals link at the top of the page, find the COBOL Programming Guide manual, and read Appendix A on Intermediate Results and Arithmetic Precision -- you will learn much. In particular, you will learn that the COBOL results you got are normal and expected based upon your data and the variable PICTURE clauses.
Back to top
View user's profile Send private message
muthurajan.b

New User


Joined: 22 Jul 2011
Posts: 6
Location: India

PostPosted: Mon Jul 25, 2011 12:04 am
Reply with quote

hi there thank you for all of you for your replies.
The reason why the cobol's result is escalated as a issue is there is another system which is parallely maintaining our data actually it is a dataware house there the rounded value ends with 7 so people are questioning hence i simulated the calculation in excel which also gives the same. I will go thru the documents also to gather knowledge about intermediate results
Back to top
View user's profile Send private message
mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Mon Jul 25, 2011 4:47 am
Reply with quote

The issue is floating point vs decimal arithmetic, excel is floating, your cobol pic values aren't they're decimal.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Jul 25, 2011 5:02 am
Reply with quote

mtaylor wrote:
The issue is floating point vs decimal arithmetic, excel is floating, your cobol pic values aren't they're decimal.


I don't think so. I think the thing is precision. If "whatever" in Excel is to 7 decimal places throughout the calculation, then the "decimal" in Cobol will give the same answer if data is defined to have the intermediates with 7 decimal places.

However, since the output is to 4 decimal places, the existing Excel calculation can give "phantom" discrepencies on occasion (potentially).

Forgetting Excel anyway, as it has just been used to provide an answer to the calculation, it is not part of the system, the question is whether one or other of the "parallel" systems is definitive, or whether both are equally valid (and should produce equal answers).
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Jul 25, 2011 5:04 am
Reply with quote

Hello,

Rather recently i learned a new term - which i instantly despised. . . This would be the term "materially correct" icon_sad.gif

Sorry, but when working money, my belief is that the answers be exact. Same with distribution units, etc. . .

Ever since people started moving data (rather than information) between platforms, this has become a bigger issue. What my teams have been rather successful doing is having ALL calculations (getting from raw data to a bit of information) done on the same platform and then distribute the answers when needed. A couple of the biggest arguments i've seen between senior managers (vp's) is when 3 of them used some raw input, ran their own processes, and came up with different answers. Their senior vp was most unhappy . . .

Another similar case involves people who know more than the data source - they add or take away things because of their own particular knowledge and perspective as to how the "thing" should be reported. . .

Thank goodness i spend more of my time with the technology issues than the political ones icon_smile.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Mon Jul 25, 2011 6:08 am
Reply with quote

Quote:
The issue is floating point vs decimal arithmetic, excel is floating, your cobol pic values aren't they're decimal.
No, you are wrong. The specific reason for the o/p problem is due to Excel doing calculations to 15 digits whereas COBOL is using fewer. If the o/p had used V9(06) (or possibly V9(08) instead) for all variables and used ROUNDED in getting the final answer with V9(04), the results probably would have been the same.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Jul 25, 2011 1:23 pm
Reply with quote

dick scherrer wrote:

[...] What my teams have been rather successful doing is having ALL calculations (getting from raw data to a bit of information) done on the same platform and then distribute the answers when needed. [...]


Even here than can be problems (I suspect you know) when shipping calculated numbers to different types (Unix, PC, Tandem, VAX, etc) of machine.

I worked at a place where they got all the "big boys" together and had a big meeting to thrash out how to pass information to an accounts package on one machine (VAX) from five other machines with different architechtures/operating systems/programming languages.

After many, many, hours over several meetings they decided on "floating point", as it was "the only format that all the machines supported" and off they went with no further thought.

The result, when they'd got everthing in production, was a 300-page accounting discrepency report showing one one-hundredth of a currency-unit discrepency on over a 1000 postings per day.

This had occured in all the development phases, but they pushed on anyway.

The systems' response to accounting was to ask if they could suppress them from the report. The guy in accounting, of course, as he should, refused, but asked that the discrepencies could be sequenced so he didn't have to hunt through 300 pages for anything larger.

Every time this accountant saw someone from systems, he would show them the report and ask what was being done about it.

I'd been "out of the loop" on this and when my system came to be integrated we discovered we had to use floating point I asked "Why?" "Because it is the only format that all the systems display", "what about plain ordinary numbers?" I asked. He thought for a few seconds, then went very red.
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1281
Location: Belgium

PostPosted: Mon Jul 25, 2011 2:31 pm
Reply with quote

intermediate rounding/cutting off, precision is not the same in all cobol compilers.

AFAIK : intemediate results are stored and cut off at the highest accuracy used. only the final calculation is ROUNDED.

(((FFF - AAA)- BBB - CCC - DDD - EEE) / (FFF - AAA)) * GGG = 0.04565 is cut off to 0.0456
(0.0456 + H) is rounded to 0.0456
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Jul 25, 2011 4:30 pm
Reply with quote

I'd agree with GuyC.

It is a very "complex" compute for something so simple.

I always do it in "stages".

You have two groups of "(add)/subtract", a divide and a multiply and an add.

I would do the "(add)/subtract"s, first.

Then the divide.

Then the multiply and the final add.

Then you can easily arrange for the precision you require.

Don't worry, four compute's is only longer than one compute by not enough for you to notice.

You do have a set of superfluous brackets. Maybe for the optimiser?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Mon Jul 25, 2011 7:37 pm
Reply with quote

With the variables AAA through HHH being V9(08) instead of V99 or V9(04), the computed result is 0.0457 instead of 0.0456 -- although I really wonder which compiler you are using since (1) you have duplicated variable AAA in your posted code, and (2) you have used OUTPUT which is a reserved word under Enterprise COBOL and hence not allowed to be a variable name as your post has it.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Jul 25, 2011 7:47 pm
Reply with quote

Hello,

Quote:
[...] What my teams have been rather successful doing is having ALL calculations (getting from raw data to a bit of information) done on the same platform and then distribute the answers when needed. [...]

Quote:
Even here than can be problems (I suspect you know) when shipping calculated numbers to different types (Unix, PC, Tandem, VAX, etc) of machine.

What i meant to say was that only "friendly" (resolved - things like $12,345,567.99) were passed about. This value would be calculated only once and distributed as needed. Regardless of platform, the number is unabiguous (won't cause strange results).

Yes, this does take a bit of planning and less "winging it". And yes, i suppose someone will find or know of a way this could cause an adventure, but it has worked very well for many. . .

A little side thought is this can reduce the transmission file size (why send 15 values when one might suffice) and why re-calculate repeatedly? And with apologies to the creative, i do tend to move as directly and simply as i can icon_smile.gif
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 3:07 am
Reply with quote

Hello Dick,

I agree completely. If there is no reason to recalculate, then there is no need to recalculate.

dick scherrer wrote:
[...]And with apologies to the creative, i do tend to move as directly and simply as i can icon_smile.gif


Personally, I think it is more creative to get a simple, logical, correct, maintainable solution, within the development schedule and which runs within the production schedule, than to do something "creative" :-)
Back to top
View user's profile Send private message
muthurajan.b

New User


Joined: 22 Jul 2011
Posts: 6
Location: India

PostPosted: Mon Aug 01, 2011 8:06 pm
Reply with quote

Hi All,

We had given a fix for the issue by introducing a intermiediate variable( declaring output variable to s9v9(7) and then rounding it to s9v9(4)) now the issue is fixed but what is the root cause?

The above issue is particular for that values i had given, not for all. I think probably it may a COBOL bug? because if i try the same formula with same data type declaration but with different values it is rounding (OMG.. OOPS icon_rolleyes.gif ). I am giving those values and output of the final values if you have time please simulate the issue and try it.

I think the value(0.045650007) is not getting round off since it is having three continues 0's before the rounding digit?


Code:
Variable name   Value1   Value2   Value3   Value4   Value5
FFF   23999.25   23999.25   23999.25   23999.25   15999.25
GGG   0.0599   0.0599   0.0599   0.0599   0.0599
CCC   878.40   898.40   938.40   958.40   999.40
BBB   0.00   0.00   0.00   0.00   0.00
DDD   0.00   0.00   0.00   0.00   0.00
EEE   0.00   0.00   0.00   0.00   0.00
HHH   0.00   0.00   0.00   0.00   0.00
AAA   19928.57   19928.57   19928.57   19928.57   11928.57
output s9v9(4)   0.0470   0.0467   0.0461   0.0458   0.0452
OUTPUT s9v9(7)   0.046974356   0.046680056   0.046091457   0.045797157   0.045193842


In all the above values it is getting rounding off.

Please let me know your concerns.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Aug 01, 2011 8:24 pm
Reply with quote

Hello,

It is not a COBOL bug icon_sad.gif

It is a lack of understanding.

There have been other "rounding" topics (some recently) that you should review as well as follow the link at the top of the page to "IBM Manuals". Read all about numerics and rounding in the COBOL documentation for your release of COBOL.

If you find something that is not clear, post what you found and your doubt. Someone will be able to clarify.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Aug 01, 2011 8:43 pm
Reply with quote

rounding the value: 0.045650007
depending upon your dp, results will be:
0.04565001
0.0456500
0.045650
0.04565
0.0457
0.046
0.05
0.1
0.

every time I hear 'it must be a COBOL bug',
99.99999% of the time we are talking with someone who does not understand computers or COBOL.

only real bugs that I have seen in IBM stuff in the last few years:
1. lot of RDZ stuff, but it is new
2. the compiler/db2-precompiler (not separate, the e-cobol combined thing)
will go out to lunch when as the last thing in LINKAGE is a DECLARE CURSOR and there is no END-EXEC.
(which means all the check-the-idiot-code stuff is not in).

have not seen any mods to cobol compiler for a while. (4 or 5 years).
Back to top
View user's profile Send private message
muthurajan.b

New User


Joined: 22 Jul 2011
Posts: 6
Location: India

PostPosted: Mon Aug 01, 2011 8:44 pm
Reply with quote

hi dick,

It can be lack of understanding if i wrote that code newly and it is not working good.

this code, which is written almost a decade before working for all the values and not working for a particular value? icon_exclaim.gif .

any way i am started to refer those manuals but i want to let you know this.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Mon Aug 01, 2011 8:50 pm
Reply with quote

Quote:
Please let me know your concerns.
MY concern is that you think this is a COBOL bug. It is not a bug. It is the way COBOL (and the mainframe -- indeed, all -- computers in general) works. Some values will round as you expect with the variables in the original post, while other values will not.

If you do not understand computer approximations used for numeric representation -- and it is very clear from the posts here that you do not -- then you are going to continue to be surprised with the way comptuers do calculations. As an example, set up a COMP-2 variable in a COBOL program, then run a loop from 1 to 30 multiplying the variable by the loop value. Do the same but run the loop from 30 to 1. The results will not be the same even though the exact same multiplications are being done. The difference is small but definitely present when you display the value. And the difference has to do with the way computers store numbers, so it cannot be removed by any manipulation you do.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Aug 01, 2011 9:02 pm
Reply with quote

Hello,

Quote:
this code, which is written almost a decade before working for all the values and not working for a particular value?
This only means that incorrect/incomplete code was promoted to production 10 years ago. It was just never detected.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Aug 01, 2011 10:29 pm
Reply with quote

dick scherrer wrote:
Hello,

Quote:
this code, which is written almost a decade before working for all the values and not working for a particular value?
This only means that incorrect/incomplete code was promoted to production 10 years ago. It was just never detected.


And 10 years of track-back on those little differences, potentially. Might be very small here, but they (probably) mean something a bit bigger somewhere else. Overcharging? Undercharging? Make sure you know that there are consquences, and that you have to let someone more senior know, and someone has to do the research for someone else (senior) to decide on the business resolution of the program error.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Aug 01, 2011 11:11 pm
Reply with quote

muthurajan.b wrote:
[...]The above issue is particular for that values i had given, not for all. I think probably it may a COBOL bug?[...]


Did anyone ask you to generate the pseudo-assembler so that you can check through what is happening to help your undestanding? Oh, yes, that was me.

Did you do that?

OMG, it is not the Compiler that is buggy, it must be the instruction set!
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia

PostPosted: Tue Aug 02, 2011 7:45 am
Reply with quote

Uh Oh! That means that every calculation/report done on the entire IBM 360 series since circa 1964 must have an impact analysis evaluation.

This will make Y2K look like child's play. Geezer full employment act here we come.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Aug 02, 2011 5:57 pm
Reply with quote

hi Bill !
Quote:
OMG, it is not the Compiler that is buggy, it must be the instruction set!

You forgot the smiley !

a general remark on the topic

anyway the instruction set is not broken, the system 360 upwards architecture contains all the instructions needed for proper rounding !
but one instruction is seldom enough ....

see here for hints on the different rounding rules
en.wikipedia.org/wiki/Rounding
and why more than one assembler instruction is needed
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming Goto page 1, 2  Next

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts Extracting Variable decimal numbers f... DFSORT/ICETOOL 17
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
Search our Forums:

Back to Top