gnubol: The many different types of numbering systems used in Cobol.

[Charlie Ebert <kd5ob@mmcable.com>]

Hi!  My name is Charlie Ebert and I've been a COBOL programmer for the insurance
industries just about
all my life.   I also like to write in C++ from time to time.

I've been on the Micro Focus Net Express BETA team for around a year helping to
get the version 3.0 out the
door.  My job has been to convert Insurance code for 13 major life insurance
firms from COBOL suitable
for a Burrow's V to Micro Focus Cobol suitable for running on a Windows
NT server.

Our process turns a Windows NT box into essentially a mainframe which is capable
of driving T-27 terminals and associated peripherals as if the old Burrows
system were still doing it.

We went live this week.  The project has been very successful for us!  I would
like to do this again
someday in either Linux or a FreeBSD port.  So I have a genuine interest in this
project and would like to
discuss the many different types of COBOL numbering system in use today to see
just which types
the GNU project are planning on supporting.

Of course there's binary and reverse binary.

What's more interesting and diverse is the various types of COMP numbering
systems which have been
invented over the years and are still in use.  Let me show you.

A COMP system differs from binary in the following way!

Let's examine the number 71 under a binary system looking at the digits first
then the hex representation.
          0100 0111 {binary}      47  {hex}
Yet under reverse binary the number 71 would show up like this.
          0111 0100 {binary}      74  {hex}

This is what Micro focus likes to refer to as COMP-5 and COMP-X respectively.

Let's take a look at the number 71 under the COMP system.
          0111 0001 {binary}      71 {hex}.

You can easily see why COMP is preferred by business people as the actual number
71 is the same
as the {hex} version every time.  So when using a database tool which displays
information in both the
ASCII and {hex} forms of a byte, one can easily read the contents of a record.

There are five different types of COMP that I'm aware of which have evolved over
the years.
Their differences become clear when you see the signed versions of the numbers
I'm about to
show you.

Let's look at a positive 71 first using each one of the 5 formats, then let's
look at a negative 71.

+71

Version 1        1100 0000 0111 0001 {binary}    C071 {hex}       PIC S9(02)
COMP or PIC S9(03) COMP.
Version 2        0000 0111 0001 1100 {binary}    071C {hex}       PIC S9(02)
COMP or PIC S9(03) COMP.
Version 3        0000 1100 0111 0001 {binary}    0C71 {hex}       PIC S9(02)
COMP.
Version 4        0111 0001 0000 1100 {binary}    710C {hex}       PIC S9(02)
COMP.
Version 5        0111 0001 1100 0000 {binary}    71C0 {hex}       PIC S9(02)
COMP.

-71
Version 1        1101 0000 0111 0001 {binary}    D071 {hex}      PIC S9(02) COMP
or PIC S9(03) COMP.
Version 2        0000 0111 0001 1101 {binary}    071D {hex}      PIC S9(02) COMP
or PIC S9(03) COMP.
Version 3        0000 1101 0111 0001 {binary}    0D71 {hex}      PIC S9(02)
COMP.
Version 4        0111 0001 0000 1101 {binary}    710D {hex}      PIC S9(02)
COMP.
Version 5        0111 0001 1101 0000 {binary}    71D0 {hex}      PIC S9(02)
COMP.

Notice that Versions 1 and 2 would be the same number of bytes used on an INTEL
box, either way.
That's because PC's are byte based machines and some mainframes are NOT.  Some
mainframes are
Digit based machines.  There are two digits per byte.  A high order digit and
low order digit make up each
byte.

ON a digit based mainframe a number like D71 or 71D being only 3 digits or 1.5
bytes is perfectly acceptable
and the CPU can even do math on it.  That's because they are machines designed
to do digit math!
They don't work with bytes they work with digits.

So you have to know some history of COBOL before you can come off with a
successful COBOL compiler
which would be of use to mainstream COBOL America.

They you can take these 5 examples I've shown you and multiply them by 2 making
10 as REVERSE
COMP is indeed out there and being done!

What happens during reverse comp in each Version I've given you is the NUMBER is
reversed but not
the sign part-'s.

Version 1 - 5 would be in reverse
Version 1        1101 0001 0111 0000 {binary}    D170 {hex}      PIC S9(02) COMP
or PIC S9(03) COMP.
Version 2        0001 0111 0000 1100 {binary}    170D {hex}      PIC S9(02) COMP
or PIC S9(03) COMP.
Version 3        0000 1101 0001 0111 {binary}    0D17 {hex}      PIC S9(02)
COMP.
Version 4        0001 0111 0000 1101 {binary}    170D {hex}      PIC S9(02)
COMP.
Version 5        0001 0111 1101 0000 {binary}    17D0 {hex}      PIC S9(02)
COMP.

Reverse COMP are my least favorite as they are hard to read with a database
browser.
They are almost as fun as reading straight binary or reverse binary.

Let's not forget about the unsigned number 71 under reverse comp being 17 {hex}.

Now, why am I writing this message to the GNU cobol folks?
If this project is to have impact upon current COBOL users we have to support
each of these version's
I've talked about.

It's totally true that if you have to convert off a DIGITS based machine such as
I've had to do, this
whole issue becomes a mess anyway!  But think of the other machines I've worked
with which are
Byte based and support one of the 10 formats of signed comp numbers you see
above.
It's so much easier to work with the data intact rather than be forced to
CONVERT everything to
some other standard.  It's such a time saver.

It took me roughly three full days of continuous CPU time to convert the
insurance files from one Burrows
mainframe to a PC system due to the Digit based to byte based systems and the
problem of the sign being
on the wrong side of the number to suite Micro Focus Cobol.  This doesn't count
the months of R&D which
went into writing the books of conversion software to accomplish this task.  I
considered the entire issue a monument of waste.  We went from a digits based
Version 2 to a byte based Version 1.  Version 1 was
all Micro focus supported and Version 2 was all Burrows supported.

If the GNU want's this compiler to be of use to COBOL America then please
support these various
COMP conventions.  Provide us with the appropriate tools to specify which type
of COMP we want
to use.  Allow us to specify this line by line, per the PIC clause in question.

I have need for buffers with mixed Binary, reverse Binary, Signed Comp 1 and
Reverse Comp 1 as well
as Display for 9 and X formats!  You literally have to be this versatile to talk
to the outside world
these days!!!

Thanks for your attention.  I hope somebody has already addressed this issue and
can give me an appropriate
run down of the GNU stance on this.


By the way.  85 supports the INSPECT command but they did away with EXAMINE yet
the two
verbs are functionally the same command.  The syntax is identical from what I've
seen.
Is there any reason to eliminate the verb EXAMINE?

Thanks again and I appologize in advance for any {binary} errors I've made!

Charlie
























--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.