Comments on COBOL Binary Arithmetic

In January of 2001 I invited William M. Klein to read my little paper on Runtime Efficiency in COBOL. Bill is the maintainer of the current COBOL FAQ (Frequently Asked Questions) on the internet, which can be found at: http://cobolreport.com/faqs/cobolfaq.htm

Bill's comments apply to IBM COBOL for OS/390 & VM, which is the currently supported release for IBM Mainframes.

Your web page looks good.  Would you like (allow) me to add a reference to
it in the COBOL FAQ?

One "specific" comment:

"For fixed-point binary arithmetic, runtime performance will be better with
the TRUNC(OPT) compile option. Don't use TRUNC(BIN), it generates a great
deal of additional code to truncate results to the target picture width. It
will also perform your arithmetic with packed-decimal numbers instead of
binary numbers."

Although I am pretty certain that this is still true "in general" - have you
tried this since the TRUNC(BIN) "optimization" that occurred as a "major"
enhancement in COBOL for OS/390 & VM V2R2? (You may also want to add
something about using TRUNC(OPT) "in general" - but using COMP-5 for
specific fields that need to be "handled" by programs - such as CICS or
DB2 - that might require "non-truncation".)

Two "enhancements" in the draft COBOL Standard would meet specific needs
that you mention.  If I were YOU (or your shop), I would look at doing an
IBM "REQUEST" (and/or SHARE requirement) to get these added - even before
IBM ever implements an ISO-200x conforming compiler - if they ever do.

A) EXIT PERFORM (EXIT PARAGRAPH and EXIT SECTION)

  This is a statement (already implemented in some compilers) that allows
you to "cleanly" jump out of a LOOP (inline or out-of-line PERFORM).  This
lets you "test" for some "bad" (error?  completion?) condition and "jump"
out of your loop without being required to do convoluted nested tests -
often requiring "tests" that should never happen within every loop.

B) SORT tables

  As you mention, doing a SEARCH ALL is a much better performer than
sequential SEARCH for even "medium-sized" tables.  However, it is often
outside the control of this program how the table is loaded.  Many/most
COBOL programmers HATE writing their own table sort routines - and when they
do, they are pretty inefficient.  With this enhancement (again, already
available in some other compilers) - it is a SIMPLE COBOL statement to SORT
a table so that you may then do SEARCH ALL on it - safely.  This also would
allow IBM (or SyncSort - or whoever's code handles the "sort") to optimize
the SORT algorithm.

Both of these enhancements are discussed (at a medium high-level) in the
CONCEPTS section of the draft Standard.

In the following comments, Bill Klein refers to Tom Ross of IBM Santa Rosa, one of the developers of the COBOL for OS/390 & VM compiler:

Feel free to use any of my comments.  However, just to be clear, I did get
verification from Tom Ross, that EVEN with the TRUNC(BIN) and/or COMP-5
performance enhancements in IBM COBOL for OS/390 & VM V2R2 that TRUNC(OPT)
is still a BETTER performer (in many/most cases).  Therefore, my
recommendation is (assuming V2R2):

A) Use TRUNC(OPT) as the default (possibly shop default - certainly
application default)

B) Use COMP-5 for those fields that MIGHT exceed their PICTURE clause.  (Use
COPY REPLACING if you are bringing in copybooks provided by CICS or DB2 that
have BINARY or COMP as the USAGE and which you actually think have "too big"
values.  The last I heard from IBM, this should NOT happen via their code -
but might if you are filling in some of the values.)

C) Do *not* use ARITH(EXTEND) unless you REALLY, really need it (possibly
for interaction with DB2). This does cause a performance "hit" even on
machines with the "hardware" to support it.

  ***

As far as I know all of these recommendations "match" IBM's.  Of course
getting to V2R2 (and a current LE) is the first step - and I think should be
"highly recommended" to those who have any choice)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Arnold,

  I did want to follow up on my BINARY/COMP note with a separate one that
MIGHT be worth considering.

First, let me say that I do not know when the draft of the next COBOL
Standard will become "official".  My STRONG expectation is that this will
happen Dec 2002 - but anything COULD happen between now and then.

The next thing to remember is that IBM has NOT explicitly stated that they
will EVER provide a fully conforming compiler - to this draft Standard.
Although I would expect that they MIGHT - if they get sufficient user
demand.  However, even when/if they do provide such a compiler, I would be
INCREDIBLY surprised if they didn't provide "upwardly compatible" support
for existing behavior - (at least as an option) even when it contradicts the
new Standard.

Having said all of that, there is one thing that programmers might want to
think about NOW - that could impact program behavior in the future.

It seems to me, that despite what
 http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGYLR205/6.1.6.2
says, IBM has (at least at some release levels - or with no more than a
W-level message) allowed an IF NUMERIC class test on BINARY/COMP fields.

The draft of the next Standard explicitly allows this BUT it requires that
the value "match" the PICTURE clause - NOT whatever can fit into the field.
Therefore, both of the following would get "false" results - when/if a
conforming (to the next COBOL Standard) compiler is produced - but they
probably reach the "true path" in today's IBM compilers.

 05  Dummy1   Value X"12345F".
    10 PD-NUM  Pic 9(4) Packed-Decimal.
 05  Dummy2   Value X"FF".
    10 Bin-Num  Pic 99 Binary.

If PD-NUM Numeric ...
If Bin-NUM Numeric ...

The bottom-line (IMHO)
  Is that COBOL programmers should NOW (if they haven't in the past) try AS
HARD AS POSSIBLE to make certain that the possible values in numeric fields
MATCH the PICTURE clauses that they use.

Click Here to return to my home page.