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

Division by zero in COBOL and TRUNC(??)


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
DB2 Guy

New User


Joined: 28 Oct 2008
Posts: 98
Location: Cubicle

PostPosted: Wed Mar 09, 2011 3:30 pm
Reply with quote

Hi,

Lately there was an abend in prod due the "Division by zero" was raised. There is a calculation involved of below type, which caused the error:
Code:
COMPUTE something =                     
                     something1 / the-cluprit                 
END-COMPUTE                                             

One solution is to check for the value of "the-cluprit" and when it's >0 allow to execute the COMPUTE, however, business says that having zeros in this field is a valid business-condition, so if I use "zero-check" that actually violates this business condition.

I looked at the TRUNC(??) option of COBOL and it looks to me that if we use TRUNC(STD) instead of TRUNC(OPT), my problem can be solved. Prod code is compiled with TRUNC(OPT). I've tried to replicate this issue in test and working on it. Though manuals also talk about ON SIZE ERROR too.

I've also checked couple of base-line program which are uisng COMPUTE, some of them have ON SIZE ERROR coded and some not, though I could not check for the compiler option for all the programs...and thinking what actually can solve my problem with minimal changes involved.

It'd be nice if some one suggest, if I'm on right track and what others have used for similar circumstances.

Thanks.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Wed Mar 09, 2011 3:42 pm
Reply with quote

as usual the question is aimed at irrelevant technicalities...

Quote:
COMPUTE something = something1 / the-cluprit
END-COMPUTE


Quote:
however, business says that having zeros in this field is a valid business-condition, so if I use "zero-check" that actually violates this business condition.

You are not violating anything
if the business condition allows a zero value somebody must tell what process to carry on

pseudocode ...
Quote:
if the-culprtit = 0 then
something = something??
else
something = something1/the-culprit


if the application had been properly designed/documented You would not have had the need to ask about zero division icon_biggrin.gif

Quote:
It'd be nice if some one suggest, if I'm on right track and what others have used for similar circumstances.

sorry to disillusion but You are taking a long an windy road
the best approach is to fix the buggy application description
( You are just a victim of somebody' s else incompetence )
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Wed Mar 09, 2011 3:51 pm
Reply with quote

Why would you think changing a compile option will suddenly resolve a divide by zero problem? There is absolutely no way that any compile option will resolve a divide by zero issue -- only application program changes will fix the issue, as enrico pointed out.
Back to top
View user's profile Send private message
DB2 Guy

New User


Joined: 28 Oct 2008
Posts: 98
Location: Cubicle

PostPosted: Wed Mar 09, 2011 5:39 pm
Reply with quote

Thanks enrico.

Robert,

Thanks for the reply.

I thought about the compiler option as the manual says:
Quote:
TRUNC(STD)
Use TRUNC(STD) to control the way arithmetic fields are truncated during MOVE and arithmetic operations. TRUNC(STD) applies only to USAGE BINARY receiving fields in MOVE statements and arithmetic expressions. When TRUNC(STD) is in effect, the final result of an arithmetic expression, or the sending field in the MOVE statement, is truncated to the number of digits in the PICTURE clause of the BINARY receiving field.
Now, when a "divison by zero" occured, receving filed was not big enough to capture the result (infinity) and an on-size-error must have raised causing the abend. If, per the bold text in the quote, I use TRUNC(STD) then such an error should not happen? icon_neutral.gif

Regards,
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Wed Mar 09, 2011 5:47 pm
Reply with quote

what is that You did not understand in Robert and my advice!

You are on the wrong track

no cobol mangling will fix a badly defined business specification!
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Mar 09, 2011 5:57 pm
Reply with quote

A"Divide by Zero" exception "0C9" is raised when this occurs, regardless whether it's a binary or packed "Divide" instruction.

The TRUNC option only applies to binary data, but has nothing to do with testing or fixing a 0C9.

Even if your compiler supports COMP-5 (Native Binary --- TRUNC is ignored), it will still be raised when the divisor is ZERO, regardless.

Time to debug this beast and find the culprit divisor.

As far as violating the "business condition" condition, where ZERO is an acceptable value, you can do as you've suggested, issue the divide only when the divisor is non-zero. How would the business weasels know the difference? Just baffle them with technical jargon (a/k/a BS) and they'll go away with their tail between their legs.

That's about all you can do....

Bill
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Wed Mar 09, 2011 6:07 pm
Reply with quote

Divide by zero is not a valid mathematical operation. TRUNC cannot be used to fix this problem as there will be no "final result of an arithmetic expression" (to quote from your reference in the manual) -- the arithmetic computation fails before a final result can be calculated.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Wed Mar 09, 2011 6:09 pm
Reply with quote

seems that the topic heading nowhere, almost time to lock it!
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Wed Mar 09, 2011 6:12 pm
Reply with quote

Quote:
seems that the topic heading nowhere, almost time to lock it!
enrico -- of course it's heading somewhere; can't you hear the flushing sound? icon_biggrin.gif
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Wed Mar 09, 2011 6:15 pm
Reply with quote

my bad... I did not hear the sound of the chain being pulled icon_biggrin.gif
Back to top
View user's profile Send private message
DB2 Guy

New User


Joined: 28 Oct 2008
Posts: 98
Location: Cubicle

PostPosted: Wed Mar 09, 2011 6:54 pm
Reply with quote

Thanks and this thread does go in some direction, I've my answer.This
Robert Sample wrote:
the arithmetic computation fails before a final result can be calculated.
and
Bill O'Boyle wrote:
As far as violating the "business condition" condition, where ZERO is an acceptable value, you can do as you've suggested, issue the divide only when the divisor is non-zero. How would the business weasels know the difference? Just baffle them with technical jargon (a/k/a BS) and they'll go away with their tail between their legs.

Helps me to reach my answer.

Thanks for your patience.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Wed Mar 09, 2011 8:54 pm
Reply with quote

Hello,

Well, i'm only a little bit late to the party. . . icon_smile.gif

An important missing bit of information is what process must be implemented when the-culprit is zero? Given that the divide by zero cannot happen, there needs to be a business rule that determines what to do when the-culprit is zero. . .

Good luck icon_smile.gif
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Wed Mar 09, 2011 9:58 pm
Reply with quote

Quote:
Well, i'm only a little bit late to the party. . .
You did not miss anything icon_biggrin.gif

as quite often happens on these forums the TS tweaked the replies in order to fit his expectations icon_evil.gif
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

 


Similar Topics
Topic Forum Replies
No new posts COBOL sorting, with input GDG base COBOL Programming 7
No new posts Need help with ADABAS query (COBOL-AD... All Other Mainframe Topics 0
No new posts Replacing FILLER with FILLER<SeqNu... DFSORT/ICETOOL 2
No new posts Compile Sp Cobol base COBOL Programming 1
No new posts SQLCODE=-311 in Cobol SP-DB2. COBOL Programming 2
Search our Forums:

Back to Top