Re: FYI: division by zero in ILE/COBOL... -- MIDRANGE-L

Hello, Michael:

In the ILE COBOL manual, it clearly states:

ILE COBOL does detect errors that result from division by zero
during an arithmetic operation. If detected by ILE COBOL, these
errors cause the SIZE ERROR imperative statement to run.

See also:
https://www-912.ibm.com/s_dir/slkbase.NSF/4636aef020ecf0688625680b00020388/b120e2d842045f198625701d004cfca9?OpenDocument&ExpandSection=-1

ANSI STANDARD COBOL
=====================
Note also that the "ANSI standard" for COBOL apparently specifies this behavior.

I found this example on another web site:

> DIVIDE 0 INTO A, B, C
>
> In accordance with the ANSI COBOL Standard, compilers allow execution to continue with unpredictable results.

I am not saying whether this is "right" or "wrong", but that may well explain why IBM chose to implement it this way in ILE COBOL, because this behavior conforms to the ANSI standard (for better or worse).

(I ran a quick test, and this is also how OPM COBOL/400 also behaves.)

Apparently, IBM mainframe COBOL for VSE is NOT ANSI-standard compliant in this respect.
Even if you submit a DCR, it might not be "accepted" by IBM. And your conversion and migration project might not be willing or able to wait for a resolution from IBM. Or, you might not be satisfied by or happy with the results.

So, you might need to consider changing all of your programs, e.g. to add "ON SIZE ERROR" etc.

Sincerely,

Mark S. Waterbury

> 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."