[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: The many different types of numbering systems used in Cobol.
Charlie,
Do you have a list of all the various comps and the compilers
that support them, even a partial list would be a good start,
Tim Josling
Charlie Ebert wrote:
>
> 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.
--
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.