Interesting. I was not aware of this particular COBOL behaviour. Swallowing the "divide by zero" error is certainly peculiar: It is both inconsistent with other programming languages AND is mathematically incorrect. I could not find any reference in the COBOL manuals that stated explicitly this is how COBOL behaves. The best I could find is in the ILE COBOL Programmer's Guide:

"For arithmetic operations and conditional expressions in ILE COBOL, when ON SIZE
ERROR is not specified and a divide by zero occurs, the results are unpredictable.
The results may be different than those that existed in OPM COBOL/ 400."

Some cursory testing shows the behaviour between OPM COBOL and ILE COBOL is different. Both dialects will swallow the "divide by zero" error condition but OPM COBOL leaves the result field untouched. ILE COBOL sets the result field to zero as you note. Both of these approaches are mathematically incorrect.

OPM COBOL's approach makes division by 0 synonymous with division by 1 for the case:
Divide r by 0 giving r.

ILE COBOL's approach breaks the rules of working with zero:
number + 0 = number
number - 0 = number
number * 0 = 0
0 / number = 0
number / 0 = undefined (or really no possible answer)

The reason division by zero is not defined (or not possible) is that successful division by zero would have the effect of making all numbers equal--a patently obvious nonsense.

It's obviously a deliberate design choice by the COBOL compiler team but I wonder why they did that? I presume it's because that's what's defined in the ANSI standard for COBOL. If that's true then VSE COBOL is not ANSI-compliant (or perhaps has a PROCESS statement or compiler option that makes it comply).

Given that there are probably COBOL programs on iSeries that depend on the current behaviour, and that it's likely the expected ANSI behaviour, I guess the best you can hope for is a compiler option (GENOPT or PROCESS statement) that can disable COBOL's default behaviour for "divide by zero". Sounds like a DCR is necessary.

On 02/10/2007, at 2:25 AM, Michael Rosinger wrote:

I wanted to post this in case some of you are unaware of this behavior in
ILE/COBOL. We are in the midst of migrating several hundred COBOL programs
from a VSE mainframe environment to ILE/COBOL on v5r3/v5r4 systems. VSE
supports a language environment (LE) similar to ILE but not nearly as
robust.

We have many programs that contain arithmetic statements that, depending on
the data passed, could potentially encounter division by zero. Practically
all of these programs are not coded with the ON SIZE ERROR clause that would
trap that exception. When division by zero does occur in the LE environment
and no exception handler is specified, the O/S gets involved, cancels the
program and produces a dump. This is the default behavior when division by
zero occurs and it is not handled by the application program.

I was shocked to discover that in ILE/COBOL this is not the case at all. If
division by zero is encountered at run-time and no exception handler is
specified (i.e. no ON SIZE ERROR clause) ILE/COBOL executes an implicit
"MOVE ZERO TO result-field" and continues normal processing with the next
statement. I have confirmed this with IBM and have an open PMR on this
issue.

For us that is a serious problem. While I agree completely that the programs
should have been written such that the program would handle the exception,
they weren't and it was acceptable to us that the O/S would trap the
problem.

Now we have a very serious problem with our migration. The IBM solution is
suppressing the problem which, when encountered, will cause other problems
that may not be apparent until a later time.

By the way, it is my understanding from conversations with others that
ILE/RPG does NOT have the same default behavior that ILE/COBOL does but does
the same thing that we are used to seeing on the mainframe, i.e. a serious
exception which forces the O/S to get involved.

I intend to continue discussions with IBM.

Are any of you as concerned about this as I am?

Here is the response I got from IBM support:

The COBOL developer provided this information:
"Using CEEHDLR will not help in this case as it requires an exception to
be raised for CEEHDLR to be called. ILE COBOL design is such that Divide by
Zero will not cause an exception to be raised, so CEEHDLR will not be
called.

Using ON SIZE ERROR and an imperative statement after every division
operation is the best way to trap this kind of error.

Please submit a Design Change Request stating that you would like to have
a PROCESS option in ILE COBOL so that it behaves in a way similar to System
z COBOL when these errors occur."


--
Regards,

Michael Rosinger
Systems Programmer / DBA
Computer Credit, Inc.
640 West Fourth Street
Winston-Salem, NC 27101
336-761-1524
m rosinger at cciws dot com



--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.



Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.