Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

COMP,COMP3 MEMORY SIZE...

Status
Not open for further replies.

kvvict

Programmer
Sep 13, 2003
5
IN
hi,

can anyone tell me how to find the no of bytes ..
for COMP,COMP1,COMP3 FIELDS ....
I KNOW THAT , COMP IS BINARY , COMP3 IS HEXADECIMAL ..
INTERNALLY STORAGE ...
BUT IF U USE A "SIGN(+ OR -)" In Comp or Comp3
fields , how much it takes memory i.e they say
1/2 nibbles or 1 nibbles ... explain..

Regards,Thanks ...
 
Go to and download file COBDATA.ZIP. It's a text and graphics tutorial on COBOL datatypes.

The above is just a generic stuff. The space taken on memory will depend on the COBOL vendor, COBOL version, and compiler options on place, so have a look at your language reference manual or users manual and search for the specifics for the COBOL you are using.




Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
COMP is usually BINARY. COMP-3 is usually PACKED-DECIMAL (not HEXADECIMAL).

Binary allocation is based on the number of digits in the PICTURE, whether it is signed, and the compiler. Here are some examples:
Code:
    No. of Digits     Micro Focus          IBM
     in Picture    Unsigned  Signed  Unsigned/Signed
    -------------  --------  ------  ---------------
        1-2           1        1            2
        3-4           2        2            2
        5-6           3        3            4
         7            3        4            4
        8-9           4        4            4
       10-11          5        5            8
        12            5        6            8
       13-14          6        6            8
       15-16          7        7            8
       17-18          8        8            8
Packed Decimal allocation is allways one more than 1/2 the number of digits, rounded down. The last nybble always contains the sign. Examples:
Code:
  Pic 9(3)     3 / 2 = 1 + 1 = 2
  Pic 9(8)     8 / 2 = 4 + 1 = 5
  Pic 9(9)     9 / 2 = 4 + 1 = 5
  Pic 9(18)   18 / 2 = 9 + 1 = 10
Some compilers provide a special format of Packed Decimal that does not use a sign nybble for unsigned fields. It is non-standard. Some vendors call it COMP-6.
 
Hi kvvict,

As you noted COMP fields are binary. The sign for these fields is carried in the hi-order bit of the field (1 is neg, 0 is pos). COMP pos/neg differs from COMP-3 and DISPLAY in that a COMP neg number is developed from the pos by applying what is called 2s complement arithmetic to the pos Comp value.

To do that you change each bit in the pos value to its complement, i.e., 1 to 0; 0 to 1, then add a binary 1. For example, a binary +1 (X'0001') is changed to -1 by "flipping the bits" - B'0000000000000001' becomes B'1111111111111110', then add 1, giving B'1111111111111111'. That's a -1 in binary notation. In Hex it looks like X'FFFF'.

That's why some of IBM's s/w tells you to move -1 to a field. It's like moving HIGH VALUES.

As far as a COMP field's length is concerned, use:

pic s9(n) COMP.

where n is 1 thru 4 the length is 2 bytes,
5 " 9 " " " 4 "
10 " 18 " " " 8 "

COMP-1&2 fields are floating point fields, and COMP-1 is a fullword (4 bytes) and COMP-2 is a double word (8 bytes).

Regards, Jack.
 
I should have mentioned that my comments were made relative to IBM mainframe compilers only. Other vendor and platform type compilers may not function in the same way.

Sorry about that - Jack.
 
The chart above with IBM and Micro Focus "storage" allocations for binary data is dependent (for Micro Focus) on several compiler options - most notably what the IBM-COMP directive is set to.

As far as Packed-Decimal (and/or COMP-3 for compilers where this is equivalent) *most* but not all compilers allow an extra nibble for the sign - even for unsigned items. HOWEVER, some do not.

Therefore,
Pic 9(4) Comp-3 (or Packed-Decimal

may take 2 bytes of storage on some compilers and 3 bytes on others.

Also, for IBM, if you have the LATEST compiler and use the
ARITH(EXTEND)
compiler option, numeric fields can be up to 31 digits and storage (either binary or Packed-decimal) may be greater than that listed above.

Finally, the SIGN IS SEPARATE clause may also impact how storage is allocaed.

Bill Klein
 
Hi,

In the listing of your compiler you can perhaps also find the length and offset of fields in memory.

What can help is:

DISPLAY LENGTH OF <identifier>

Regards,

Crox
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top