| Author |
Max integer in an 8 byte COMP field?
|
|
| Graham Hobbs 2007-04-20, 9:55 pm |
| Hello,
I can't figure this out.
Am trying to find the largest integer that will fit inside a 'comp'
field of 8 bytes (64 bits).
Below is the compiler output followed by execution results.
I tried with both signed and unsigned COMP fields.
I can understand why exponents of 64 and 65 go to zero (I think) but:
1. why at 62 does the displayed result have 19 digits (when my Cobol
manuals tell me 18 is the maximum).
2. same for 63, but additionally, why has it gone negative.
3. I still don't know what the largest integer can be.
Any ideas please, thanks.
Graham Hobbs
...............................................
Compiler (VisualAge Cobol V2.2) output:
000091 05 RES1 PIC 9(18) COMP. 8(0000221)
000092 05 RES2 PIC S9(18) COMP. 8(0000229)
000115 DISPLAY '--------------------------------'
000116 COMPUTE RES1 = 2 ** 62 DISPLAY ' RES1=' RES1
000117 COMPUTE RES1 = 2 ** 63 DISPLAY ' RES1=' RES1
000118 COMPUTE RES1 = 2 ** 64 DISPLAY ' RES1=' RES1
000119 COMPUTE RES1 = 2 ** 65 DISPLAY ' RES1=' RES1
000120 DISPLAY '--------------------------------'
000121 COMPUTE RES2 = 2 ** 62 DISPLAY ' RES2=' RES2
000122 COMPUTE RES2 = 2 ** 63 DISPLAY ' RES2=' RES2
000123 COMPUTE RES2 = 2 ** 64 DISPLAY ' RES2=' RES2
000124 COMPUTE RES2 = 2 ** 65 DISPLAY ' RES2=' RES2
000125 DISPLAY '--------------------------------'
Results:
-------------------------------
RES1=4611686018427387904
RES1=-9223372036854775808
RES1=0000000000000000000
RES1=0000000000000000000
-------------------------------
RES2=4611686018427387904
RES2=-9223372036854775808
RES2=0000000000000000000
RES2=0000000000000000000
-------------------------------
Cheers
--
Posted via a free Usenet account from http://www.teranews.com
| |
| Roger While 2007-04-21, 3:55 am |
| And nobody spotted the mistake :-)
Should be -
WORKING-STORAGE SECTION.
01 rc1 pic 9(18) comp.
01 rc2 pic s9(18) comp.
01 rc3 pic 9(18) comp-5.
01 rc4 pic s9(18) comp-5.
Revised results -
simlinux:~ # cobc -x -std=mf ltest.cob
simlinux:~ # ./ltest
PIC 9(18) COMP.
04611686018427387904
09223372036854775808
18446744073709551615
PIC S9(18) COMP.
+04611686018427387904
+00000000000000000000
+09223372036854775807
PIC 9(18) COMP-5.
04611686018427387904
09223372036854775808
18446744073709551615
PIC S9(18) COMP-5.
+04611686018427387904
+00000000000000000000
+09223372036854775807
simlinux:~ # cobc -x -std=cobol2002 ltest.cob
simlinux:~ # ./ltest
PIC 9(18) COMP.
000000000000000000
000000000000000000
000000000000000000
PIC S9(18) COMP.
+000000000000000000
+000000000000000000
+000000000000000000
PIC 9(18) COMP-5.
611686018427387904
223372036854775808
446744073709551615
PIC S9(18) COMP-5.
+611686018427387904
+000000000000000000
+223372036854775807
"Roger While" <simrw@sim-basis.de> schrieb im Newsbeitrag
news:f0atam$rlj$02$1@news.t-online.com...
> simlinux:~ # cat ltest.cob
> IDENTIFICATION DIVISION.
> PROGRAM-ID. LTEST.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 rc1 pic 9(18) comp.
> 01 rc2 pic s9(18) comp-5.
> 01 rc3 pic 9(18) comp.
> 01 rc4 pic s9(18) comp-5.
> PROCEDURE DIVISION.
> display "PIC 9(18) COMP."
> compute rc1 = 2 ** 62.
> display rc1.
> compute rc1 = 2 ** 63.
> display rc1.
> compute rc1 = 2 ** 64 - 1.
> display rc1.
> display "PIC S9(18) COMP."
> compute rc2 = 2 ** 62.
> display rc2.
> compute rc2 = 2 ** 63.
> display rc2.
> compute rc2 = 2 ** 64 - 1.
> display rc2.
> display "PIC 9(18) COMP-5."
> compute rc3 = 2 ** 62.
> display rc3.
> compute rc3 = 2 ** 63.
> display rc3.
> compute rc3 = 2 ** 64 - 1.
> display rc3.
> display "PIC S9(18) COMP-5."
> compute rc4 = 2 ** 62.
> display rc4.
> compute rc4 = 2 ** 63.
> display rc4.
> compute rc4 = 2 ** 64 - 1.
> display rc4.
> STOP RUN.
>
> With OC -
> simlinux:~ # cobc -x -std=mf ltest.cob
> simlinux:~ # ./ltest
> PIC 9(18) COMP.
> 04611686018427387904
> 09223372036854775808
> 18446744073709551615
> PIC S9(18) COMP.
> +04611686018427387904
> +00000000000000000000
> +09223372036854775807
> PIC 9(18) COMP-5.
> 04611686018427387904
> 09223372036854775808
> 18446744073709551615
> PIC S9(18) COMP-5.
> +04611686018427387904
> +00000000000000000000
> +09223372036854775807
>
> Note, need the std=mf otherwise result would be default
> be not calculated if precision exceeds pic definition.
>
> Interesting -
> MF SE 2.2 -
> simlinux:~ # cob -u -C notrunc ltest.cob
> simlinux:~ # cobrun ltest
> PIC 9(18) COMP.
> 611686018427387904
> 223372036854775808
> 446744073709551615
> PIC S9(18) COMP.
> +611686018427387904
> -223372036854775808
> -000000000000000001
> PIC 9(18) COMP-5.
> 611686018427387904
> 223372036854775808
> 446744073709551615
> PIC S9(18) COMP-5.
> +611686018427387904
> -223372036854775808
> -000000000000000001
>
> What is correct I will leave the Gurus to work out :-)
>
> Roger
>
> "Graham Hobbs" <ghobbs@cdpwise.net> schrieb im Newsbeitrag
> news:j9nh23lfuelrdtvktcjh84ugd6s9kjh51u@
4ax.com...
>
>
| |
| Roger While 2007-04-21, 3:55 am |
| Tried this with MF SE 4 at customer site, interesting -
cob -u -C NOTRUNC ltest.cob
cobrun ./ltest
PIC 9(18) COMP.
611686018427387904
223372036854775808
446744073709551615
PIC S9(18) COMP.
+611686018427387904
-223372036854775808
-000000000000000001
PIC 9(18) COMP-5.
611686018427387904
223372036854775808
446744073709551615
PIC S9(18) COMP-5.
+611686018427387904
-223372036854775808
-000000000000000001
(with the correction below)
"Roger While" <simrw@sim-basis.de> schrieb im Newsbeitrag
news:f0cgvt$bpi$01$1@news.t-online.com...
> And nobody spotted the mistake :-)
> Should be -
> WORKING-STORAGE SECTION.
> 01 rc1 pic 9(18) comp.
> 01 rc2 pic s9(18) comp.
> 01 rc3 pic 9(18) comp-5.
> 01 rc4 pic s9(18) comp-5.
>
> Revised results -
> simlinux:~ # cobc -x -std=mf ltest.cob
> simlinux:~ # ./ltest
> PIC 9(18) COMP.
> 04611686018427387904
> 09223372036854775808
> 18446744073709551615
> PIC S9(18) COMP.
> +04611686018427387904
> +00000000000000000000
> +09223372036854775807
> PIC 9(18) COMP-5.
> 04611686018427387904
> 09223372036854775808
> 18446744073709551615
> PIC S9(18) COMP-5.
> +04611686018427387904
> +00000000000000000000
> +09223372036854775807
> simlinux:~ # cobc -x -std=cobol2002 ltest.cob
> simlinux:~ # ./ltest
> PIC 9(18) COMP.
> 000000000000000000
> 000000000000000000
> 000000000000000000
> PIC S9(18) COMP.
> +000000000000000000
> +000000000000000000
> +000000000000000000
> PIC 9(18) COMP-5.
> 611686018427387904
> 223372036854775808
> 446744073709551615
> PIC S9(18) COMP-5.
> +611686018427387904
> +000000000000000000
> +223372036854775807
>
> "Roger While" <simrw@sim-basis.de> schrieb im Newsbeitrag
> news:f0atam$rlj$02$1@news.t-online.com...
>
>
| |
| William M. Klein 2007-04-22, 7:55 am |
| It better NOT have any "COMP-5" data if using VisualAge COBOL (as I think the
OP stated),
Although IBM *now* supports COMP-5 on most (still not all) platforms, I am
pretty certain that VisualAge COBOL did not include it.
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:f0cgvt$bpi$01$1@news.t-online.com...
> And nobody spotted the mistake :-)
> Should be -
> WORKING-STORAGE SECTION.
> 01 rc1 pic 9(18) comp.
> 01 rc2 pic s9(18) comp.
> 01 rc3 pic 9(18) comp-5.
> 01 rc4 pic s9(18) comp-5.
>
> Revised results -
> simlinux:~ # cobc -x -std=mf ltest.cob
> simlinux:~ # ./ltest
> PIC 9(18) COMP.
> 04611686018427387904
> 09223372036854775808
> 18446744073709551615
> PIC S9(18) COMP.
> +04611686018427387904
> +00000000000000000000
> +09223372036854775807
> PIC 9(18) COMP-5.
> 04611686018427387904
> 09223372036854775808
> 18446744073709551615
> PIC S9(18) COMP-5.
> +04611686018427387904
> +00000000000000000000
> +09223372036854775807
> simlinux:~ # cobc -x -std=cobol2002 ltest.cob
> simlinux:~ # ./ltest
> PIC 9(18) COMP.
> 000000000000000000
> 000000000000000000
> 000000000000000000
> PIC S9(18) COMP.
> +000000000000000000
> +000000000000000000
> +000000000000000000
> PIC 9(18) COMP-5.
> 611686018427387904
> 223372036854775808
> 446744073709551615
> PIC S9(18) COMP-5.
> +611686018427387904
> +000000000000000000
> +223372036854775807
>
> "Roger While" <simrw@sim-basis.de> schrieb im Newsbeitrag
> news:f0atam$rlj$02$1@news.t-online.com...
>
>
| |
| Graham Hobbs 2007-04-22, 7:55 am |
| Always a chance I'm misunderstanding something, but this is the
VisualAge COBOL 2.2 compiler output from one of my copybooks.
I did this copybook a long time ago and it looks like it is the
product of a DCLGEN. There are several comp-5 fields.
Sorry about the format (I thought if you copied something in 'Courier
New' all would be well).
01 ALLTYP1. 32886
05 ABIGINT PIC S9(18) COMP-5. 8(0000000)
05 ABLOB USAGE IS SQL TYPE IS BLOB(40). 44(0000008)
4(0000008)
40(0000012)
05 ACHAR PIC X(10). 10(0000052)
05 ACLOB USAGE IS SQL TYPE IS CLOB(41). 45(0000062)
4(0000062)
41(0000066)
05 ADATE PIC X(10). 10(0000107)
05 ADECIMAL PIC S9(5)V COMP-3. 3(0000117)
05 ADOUBLE USAGE IS COMP-2. 8(0000120)
05 AINTEGER PIC S9(9) COMP-5. 4(0000128)
05 ALONGVARCHAR. 32702(0000132)
49 ALONGVARCHARL PIC S9(4) COMP-5. 2(0000132)
49 ALONGVARCHARD PIC X(32700). 32700(0000134)
05 AREAL USAGE IS COMP-1. 4(0032834)
05 ASMALLINT PIC S9(4) COMP-5. 2(0032838)
05 ATIME PIC X(8). 8(0032840)
05 ATIMESTAMP PIC X(26). 26(0032848)
05 AVARCHAR. 12(0032874)
49 AVARCHARL PIC S9(4) COMP-5. 2(0032874)
49 AVARCHARD PIC X(10). 10(0032876)
Graham
On Sat, 21 Apr 2007 16:59:19 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>It better NOT have any "COMP-5" data if using VisualAge COBOL (as I think the
>OP stated),
>
>Although IBM *now* supports COMP-5 on most (still not all) platforms, I am
>pretty certain that VisualAge COBOL did not include it.
--
Posted via a free Usenet account from http://www.teranews.com
| |
| James J. Gavan 2007-04-23, 7:55 am |
| Graham Hobbs wrote:
> Always a chance I'm misunderstanding something, but this is the
> VisualAge COBOL 2.2 compiler output from one of my copybooks.
> I did this copybook a long time ago and it looks like it is the
> product of a DCLGEN. There are several comp-5 fields.
> Sorry about the format (I thought if you copied something in 'Courier
> New' all would be well).
Graham,
Not in answer to your query but your comment about the source yo-yo-ing
all over the place. I've had similar problems when typing e-mails. Just
submitted one recently, having moved stuff around and the bloody thing
is all over the place.
As regards code this is what I do - and hopefully works in small samples
coming up :-)
Might be the editor one uses but I bring up a source in Net Express
using fixed format, (using their default font, whatever that is).
1 - Here I have block highlighted from Column 1 to 72 :-
*>-------------------------------------------------------------
OBJECT.
*>--------------------------------------------------------------
WORKING-STORAGE SECTION.
01 charx pic x.
01 ws-choice pic x(4) comp-5.
88 ofReferences value 1.
88 ofValues value 2.
01 ws-length pic x(4) comp-5.
01 ws-size pic x(4) comp-5.
01 ws-WildCardName.
05 pic x occurs 1 to 100 depending on ws-length.
*> OBJECTS
01 os-OrderedOfReferences object reference value null.
01 os-SortedCollection object reference value null.
2 - Here I have highlighted from Column 8 to 72 :--
*>-------------------------------------------------------------
OBJECT.
*>--------------------------------------------------------------
WORKING-STORAGE SECTION.
01 charx pic x.
01 ws-choice pic x(4) comp-5.
88 ofReferences value 1.
88 ofValues value 2.
01 ws-length pic x(4) comp-5.
01 ws-size pic x(4) comp-5.
01 ws-WildCardName.
05 pic x occurs 1 to 100 depending on ws-length.
*> OBJECTS
01 os-OrderedOfReferences object reference value null.
01 os-SortedCollection object reference value null.
Might not work for you - but #1 is the one I use.
Jimmy
| |
|
|
|
|