COMP vs. COMP-5

Greetings,

I just need a sanity check on my understanding of COMP, COMP-5.  My
understanding is that, in terms of value representation, these two are
identical.

That is, if I'm confronted with a compiler that does not like COMP-5, I
can just change things to COMP without having to rethink my PIC clauses.
They are both binary representations of a given size.

My understanding is that it is the internal representation that is
different, primarily that COMP-5 values can be stored in a smaller space
than COMP.
--
cm

On Mon, 29 Mar 2004 11:17:12 -0500, clvrmnky
<clvrmnky-uunet@coldmail.com.invalid> wrote:

>Greetings,
>
>I just need a sanity check on my understanding of COMP, COMP-5.  My
>understanding is that, in terms of value representation, these two are
>identical.
>
>That is, if I'm confronted with a compiler that does not like COMP-5, I
>can just change things to COMP without having to rethink my PIC clauses.
>They are both binary representations of a given size.
Which compiler (vendor and version) are you using?
>
>My understanding is that it is the internal representation that is
>different, primarily that COMP-5 values can be stored in a smaller space
>than COMP.
compiler dependent, along with compile options in force.



Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

On 29/03/2004 11:49 AM, Frederico Fonseca wrote:

> On Mon, 29 Mar 2004 11:17:12 -0500, clvrmnky
> <clvrmnky-uunet@coldmail.com.invalid> wrote: 
>
> Which compiler (vendor and version) are you using?
>
IBM COBOL for OS/390 & VM  2.1.1

On 29/03/2004 12:09 PM, clvrmnky wrote:

> On 29/03/2004 11:49 AM, Frederico Fonseca wrote:
> 
> IBM COBOL for OS/390 & VM  2.1.1

... which implies that I need 2.2.0 or higher to get COMP-5 support
(which is what I developed the application on).

I'm trying to support my code remotely, via some of our field engineers
who are deploying a proof-of-concept in Europe.

So, when faced with this case, I have to try and understand COMP-5 vs.
COMP and COMP-3 (or COMP-4?) TRUNCATE BINARY.
--
cm

For IBM COBOLs at your release level, a program compiled with TRUNC(BIN) usi
ng
COMP and a program that uses COMP-5 for *all* binary items regardless of TRU
NC
setting should use identical internal storage and produce identical results.

As TRUNC(BIN) is an INCREDIBLY inefficient (bad performance) option, if you 
use
COMP (rather than COMP-5) for binary items with TRUNC(OPT) or TRUNC(STD), th
en
you will get different object code - but your data items will be stored
identically.

NONE of this is (necessarily) portable to other compilers (IBM on different
platforms or any other PC or Unix compiler).

--
Bill Klein
wmklein <at> ix.netcom.com
"clvrmnky" <clvrmnky-uunet@coldmail.com.invalid> wrote in message
news:0VY9c.11829$kc2.274357@nnrp1.uunet.ca...
> On 29/03/2004 12:09 PM, clvrmnky wrote:
> 
>
> ... which implies that I need 2.2.0 or higher to get COMP-5 support
> (which is what I developed the application on).
>
> I'm trying to support my code remotely, via some of our field engineers
> who are deploying a proof-of-concept in Europe.
>
> So, when faced with this case, I have to try and understand COMP-5 vs.
> COMP and COMP-3 (or COMP-4?) TRUNCATE BINARY.
> --
> cm

clvrmnky wrote:
>
> ... which implies that I need 2.2.0 or higher to get COMP-5 support
> (which is what I developed the application on).
>
> I'm trying to support my code remotely, via some of our field
> engineers who are deploying a proof-of-concept in Europe.
>
> So, when faced with this case, I have to try and understand COMP-5 vs.
> COMP and COMP-3 (or COMP-4?) TRUNCATE BINARY.

COMP-5
COMP-4
and
COMP-3

are (ususally) completely separate representations of data and are not
interchangable.

COMP is (usually) your compiler's default designation for one of the above.
That is, on some compilers, COMP=COMP-4 and other compilers COMP=COMP-5. To
make matters worse, the compiler can default COMP one way and compiler
options you set can force it to something else.

First, I recommend you stay away from COMP and explicitly define the
representation by adding the "-x" directive to data fields.

If your compiler does not like COMP-5, then it probably likes COMP-4.

COMP-3 is packed decimal and markedly different, in all respects, from the
other two. To begin, it is decimal, not binary.

For this specific compiler
COMP, COMP-4, and COMP-5 (and BINARY) are "identical" if one compiles with
TRUNC(BIN)
COMP and COMP-4 (and BINARY) are identical regardless of the TRUNC compiler
option
(but are NOT the same as COMP-5)  as far as "logic" goes - but are the
same as far as internal storage goes.  (The
difference is in the handling of items whose "contents" are larger than
what the PICTURE clause specifies).

COMP-3 (and Packed-Decimal) are identical regardless of any compiler option 
and
are always "packed-decimal" for storage.

Again, this is NOT portable across compilers or operating systems.

For examples of exactly how the binary feature works with the different opti
ons
(for THIS compiler), look at the examples at:
http://publibz.boulder.ibm.com/cgi-...y3pg20/2.4.52.1

and
http://publibz.boulder.ibm.com/cgi-...y3pg20/2.4.52.1

Remember that COMP-5 items *always* works as these examples describe TRUNC(B
IN)
behavior.

--
Bill Klein
wmklein <at> ix.netcom.com
"JerryMouse" <nospam@bisusa.com> wrote in message
news:MNOdnYj5KqSrP_XdRVn-jg@giganews.com...
> clvrmnky wrote: 
>
> COMP-5
> COMP-4
> and
> COMP-3
>
> are (ususally) completely separate representations of data and are not
> interchangable.
>
> COMP is (usually) your compiler's default designation for one of the above
.
> That is, on some compilers, COMP=COMP-4 and other compilers COMP=COMP-5. T
o
> make matters worse, the compiler can default COMP one way and compiler
> options you set can force it to something else.
>
> First, I recommend you stay away from COMP and explicitly define the
> representation by adding the "-x" directive to data fields.
>
> If your compiler does not like COMP-5, then it probably likes COMP-4.
>
> COMP-3 is packed decimal and markedly different, in all respects, from the
> other two. To begin, it is decimal, not binary.
>
>

On 29/03/2004 5:38 PM, William M. Klein wrote:

> For this specific compiler
>   COMP, COMP-4, and COMP-5 (and BINARY) are "identical" if one compiles wi
th
> TRUNC(BIN)
>   COMP and COMP-4 (and BINARY) are identical regardless of the TRUNC compi
ler
> option
>         (but are NOT the same as COMP-5)  as far as "logic" goes - but are
 the
> same as far as internal storage goes.  (The
>         difference is in the handling of items whose "contents" are larger
 than
> what the PICTURE clause specifies).
>
> COMP-3 (and Packed-Decimal) are identical regardless of any compiler optio
n and
> are always "packed-decimal" for storage.
>
> Again, this is NOT portable across compilers or operating systems.
>
> For examples of exactly how the binary feature works with the different op
tions
> (for THIS compiler), look at the examples at:
>    [url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg20/2.4.52.1[
/url]
>
> and
>   [url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg20/2.4.52.1[/
url]
>
> Remember that COMP-5 items *always* works as these examples describe TRUNC
(BIN)
> behavior.
>

This is good stuff.  In the interest in maintaining as much portability
as possible, I'm going to change all COMP-5 to BINARY and hope for the
best.  We can tweak compiler options as necessary, I guess.

The only place I've used these types of values is in structures passed
to/from EZASOKET CALLs (e.g., for the "s-addr" struct).  AFAIKT, on any
390 box, as long as I have the PIC correct, BINARY values should be OK.

I'm not sure _why_ I chose COMP-5 in my original code.  It may have been
a combination of ignorance and having to development on VisualAge for
Cobol on Win32, and talking to Winsock.  On the 390 I should be OK with
BINARY, from what I've been reading.

Thanks to all for your comments and suggestions.
--
cm