Not being a "C" programmer I need a translation of Binary-Long to real COBOL.
I am using an x86 machine.
The PG has 300+ references to "binary-long"
I could not find a translation in the PG.
Thanks
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-12-24
The attached GnuCOBOL program can be used to determine sizes for various data types.
I speculate that all on the "BINARY" data fields are little endian - correct ?
So from what can discern BINARY-LONG would be in COBOL PIC 9(08) COMP-5.
Yes ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Binary for is subject to the CPU you are using so it can be Big or small.
Bin-long hold 4 bytes in a X64 CPU.
On 24/12/2024 02:19, Ralph Linkletter wrote:
I speculate that all on the "BINARY" data fields are little endian -
correct ?
So from what can discern BINARY-LONG would be in COBOL PIC 9(08) COMP-5.
Yes ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not being a "C" programmer I need a translation of Binary-Long to real COBOL.
I am using an x86 machine.
The PG has 300+ references to "binary-long"
I could not find a translation in the PG.
Thanks
Ralph
The attached GnuCOBOL program can be used to determine sizes for various data types.
I speculate that all on the "BINARY" data fields are little endian - correct ?
So from what can discern BINARY-LONG would be in COBOL PIC 9(08) COMP-5.
Yes ?
They are "native", so on x86 little-endian.
I'd have to recheck but think that SIGNED is the default, so that would make it S9(9) COMP-5.
Binary for is subject to the CPU you are using so it can be Big or small.
Bin-long hold 4 bytes in a X64 CPU.
On 24/12/2024 02:19, Ralph Linkletter wrote:
From what I see, binary-long is the same as comp-x and is 4 bytes in gnucobol 32 or 64 bit.
I missed my sign-in.
The "usagelen.COB" program will show the lengths of various data types.
resulting in
Last edit: Simon Sobisch 2025-02-04