MF COMP-5 (was MF COBOL and IBM data types) 
Author Message
 MF COMP-5 (was MF COBOL and IBM data types)

Quote:

>     As I understand it, comp-5 is supposed to be a system dependant format,
> normally used for
> speed purposes.  Ie, on an Intel box running dos/windows comp-5 would be in
> intel endian format,
> ie backwards.  On the other hand the other binary items are in non-intel
> format.

OK, I'll bite.

Why would a compiler *not* use the native system format for BINARY
or COMP data in the first place, thus requiring a COMP-5 to get
next to the hardware?

Regards,
Jared Thomas

http://www.*-*-*.com/ ~jmthomas



Fri, 19 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)
    Portability is the most likely reason.  Most systems (many?) seem to use
the Motorola layout for binary data.  This allows systems to exchange binary
data, it makes sorting (unsigned binary at least) easier, it allows normal
humans to look at the hex value of a comp (binary) item.

    Whomever thought up the Intel binary format must have been on {*filter*},
IMHO.

    Of course, this would slow down math somewhat.  Now that 32 bit and even
64 bit math can be done on native data, it might be helpfull to use COMP-5
more often.


Quote:

> >     As I understand it, comp-5 is supposed to be a system dependant
format,
> > normally used for
> > speed purposes.  Ie, on an Intel box running dos/windows comp-5 would be
in
> > intel endian format,
> > ie backwards.  On the other hand the other binary items are in non-intel
> > format.

> OK, I'll bite.

> Why would a compiler *not* use the native system format for BINARY
> or COMP data in the first place, thus requiring a COMP-5 to get
> next to the hardware?

> Regards,
> Jared Thomas

> http://www.*-*-*.com/ ~jmthomas



Sat, 20 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)

Quote:

>Why would a compiler *not* use the native system format for BINARY
>or COMP data in the first place, thus requiring a COMP-5 to get
>next to the hardware?

Jared,
        In a word: portability (or compatibility). If you share data it
needs to be in a consistent format. Consider a system where you have Intel
and non-Intel clients sharing data. If the data was stored in native format
there would be serious problems sharing that data.


Sat, 20 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)
Because the same Cobol program often runs on multiple platforms.

Quote:


>>     As I understand it, comp-5 is supposed to be a system dependant
format,
>> normally used for
>> speed purposes.  Ie, on an Intel box running dos/windows comp-5 would be
in
>> intel endian format,
>> ie backwards.  On the other hand the other binary items are in non-intel
>> format.

>OK, I'll bite.

>Why would a compiler *not* use the native system format for BINARY
>or COMP data in the first place, thus requiring a COMP-5 to get
>next to the hardware?

>Regards,
>Jared Thomas

>http://www.radiks.net/~jmthomas



Sat, 20 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)

Quote:


> >Why would a compiler *not* use the native system format for BINARY
> >or COMP data in the first place, thus requiring a COMP-5 to get
> >next to the hardware?

> Jared,
>         In a word: portability (or compatibility). If you share data it
> needs to be in a consistent format. Consider a system where you have Intel
> and non-Intel clients sharing data. If the data was stored in native format
> there would be serious problems sharing that data.

And about compatibility. When Mr. Gates issued his last-but-one COBOL
he warned don't use Comp-5 in files. Then when he issued the last (which
was MicroFocus) - he commented "See...?".

Jimmy, Calgary AB



Sat, 20 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)

Quote:


>:>
>:>Why would a compiler *not* use the native system format for BINARY
>:>or COMP data in the first place, thus requiring a COMP-5 to get
>:>next to the hardware?

>Because data is shipped between computer systems.

>A record with a COMP field had better be identical on ALL implementations of
>COBOL.

Au contraire.  The COBOL 85 standard specifically defines usage COMP
to be implementor defined.  I suspect Micro Focus chose to make COMP
a big-endian binary is to be compatible with IBM mainframes, and they
added COMP-5 to permit efficient use of little-endian binary on Intel
PCs when desired.
--

Sun Valley Systems    http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


Sat, 20 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)

   [ snipped ]

:>Why would a compiler *not* use the native system format for BINARY
:>or COMP data in the first place, thus requiring a COMP-5 to get
:>next to the hardware?

Because data is shipped between computer systems.

A record with a COMP field had better be identical on ALL implementations of
COBOL.

Perhaps it is worth defining a non-interchangeable data type for efficiency?

--


http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Sun, 21 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)


Quote:
> Jared,
>         In a word: portability (or compatibility). If you share data
it
> needs to be in a consistent format.

Yes, BUT, if you use COMP-5 internally for indexes, counters,
and the like, AND don't share these internal variables,
why not get the 50% (or 10% or 1%) increase in efficiency?

And, of course, calling system functions may mandate that
you use the hardware-native formats.

So there are uses for COMP-5.



Sun, 21 Apr 2002 03:00:00 GMT  
 MF COMP-5 (was MF COBOL and IBM data types)

Quote:


> >:>
> >:>Why would a compiler *not* use the native system format for BINARY
> >:>or COMP data in the first place, thus requiring a COMP-5 to get
> >:>next to the hardware?

> >Because data is shipped between computer systems.

> >A record with a COMP field had better be identical on ALL implementations
of
> >COBOL.

> Au contraire.  The COBOL 85 standard specifically defines usage COMP
> to be implementor defined.  I suspect Micro Focus chose to make COMP
> a big-endian binary is to be compatible with IBM mainframes, and they
> added COMP-5 to permit efficient use of little-endian binary on Intel
> PCs when desired.

and provides various compiler directives so you CAN use "COMP" to mean
COMP-5 - if that is what you want.

--
Bill Klein
    wmklein <at> ix dot netcom dot com



Mon, 22 Apr 2002 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. MF COMP-5 (was MF COBOL and IBM data types)

2. MF COBOL and IBM data types

3. converting from MF cobol to IBM VA Cobol

4. Migrating MF-COBOL to IBM VA for COBOL

5. Info/Advice needed on IBM Cobol 2 to MF Unix Cobol conversion

6. MF Cobol VS MF WorkBench

7. MF Cobol and IBM DB2

8. MF COBOL with Encina SFS on IBM RS/6000

9. IBM MF, MVS, CICS, COBOL, VSAM position available in Research Triangle Park area

10. Converting Files with COMP-6 to MF COBOL

11. COMP-2 precision loss in MF Cobol

12. Data file creating/editing using MF Personal COBOL

 

 
Powered by phpBB® Forum Software