2's complement of COMP fileds



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

2's complement of COMP fileds

Postby Suganya.Shanmugam » Tue Jan 18, 2011 12:42 pm

Hi,
for the COMP fields how the negative numbers will be stored in the file.
i have learnt that Most significant will be ON for negative and will be stored in 2's complement form.
Please tell me whether all the bits of that wil be in 2's complement.
For ex: if i am having the COMP fields stored in the file with the hex value 4DE13911.
In this case bin value of 4 is 0100. it means that MSB is 0 and the number is +ve. But my doubt is whether 0100 alone will be stored in 2's complement form or entire value 01001101111000010011100100010001 will be stored in 2's complement.

thanks,
ss
Suganya.Shanmugam
 
Posts: 7
Joined: Thu Nov 11, 2010 10:57 am
Has thanked: 0 time
Been thanked: 0 time

Re: 2's complement of COMP fileds

 

Re: 2's complement of COMP fileds

Postby Robert Sample » Tue Jan 18, 2011 5:05 pm

Simple rule of thumb for COMP (binary) variables: if the first bit is 0, the number is positive and if the first bit is 1, the number is negative. If the first bit is 1, the entire value (16, 32, or 64 bits) is in two's complement notation.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: 2's complement of COMP fileds

Postby Schubie » Wed Jan 26, 2011 1:20 pm

Also remember that the smallest usable binary number is a halfword or 2 bytes. COBOL's S9(1) COMP will be a halfword. Even using Assembler, trying to work with a signed single byte binary takes too much code to properly treat a number whose maximum value would only be 126 and COBOL won't do it anyhow.
If a bug is located in a program product which simply cannot be fixed, it becomes a 'feature'. (IBM)
User avatar
Schubie
 
Posts: 10
Joined: Wed Jul 21, 2010 9:16 am
Location: Blue Ridge, GA USA
Has thanked: 0 time
Been thanked: 0 time

Re: 2's complement of COMP fileds

Postby dick scherrer » Thu Jan 27, 2011 12:08 am

Hello,

and COBOL won't do it anyhow.
Sure it will - if there is proper code. . . REDEFINES is our friend. . .
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: 2's complement of COMP fileds

Postby Schubie » Wed Feb 02, 2011 12:59 pm

Dick is right, with enough code and redefinitions, it can be done.. it's just a PITA.
If a bug is located in a program product which simply cannot be fixed, it becomes a 'feature'. (IBM)
User avatar
Schubie
 
Posts: 10
Joined: Wed Jul 21, 2010 9:16 am
Location: Blue Ridge, GA USA
Has thanked: 0 time
Been thanked: 0 time

Re: 2's complement of COMP fileds

Postby BillyBoyo » Wed Feb 02, 2011 1:31 pm

Robert Sample wrote:Simple rule of thumb for COMP (binary) variables: if the first bit is 0, the number is positive and if the first bit is 1, the number is negative. If the first bit is 1, the entire value (16, 32, or 64 bits) is in two's complement notation.


Schubie wrote:Also remember that the smallest usable binary number is a halfword or 2 bytes. COBOL's S9(1) COMP will be a halfword. Even using Assembler, trying to work with a signed single byte binary takes too much code to properly treat a number whose maximum value would only be 126 and COBOL won't do it anyhow.


Definitely be careful with things like COMP S9(1) (or 2 or 3 or 5 6 7 - can't remember if 8 is a problem, compile with S9(9), if no messages, then 8 is a problem as well). Although COBOL will always resevere space on a half-word boundary for binary fields, you can't necessarily "use" all that space. COMP S9(1) will contain only -9 to +9. S9(2), -99 to +99. If you look at the binary of those, it is as Robert Sample says, all the minuses will have high-order-bit set to 1, and value in 2's complement. -1 for any COBOL COMP S9(n) will show as a whole bunch of F's.

What do you have to be careful of? Different results depending on compiler options. I always used to code COMP PIC S9(4) and explicitly make sure +/- 9999 could not be exceeded. Else, one day, you'll get a problem.


Maybe it is no longer true, but I'd guess it is, someone will point it out if it is wrong.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: 2's complement of COMP fileds

Postby enrico-sorichetti » Wed Feb 02, 2011 2:33 pm

appendix A of
z_Architecture_Principles_of_Operation
SA22_7832_08
will tell all You might want to know about number representation and quirks
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2643
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

Re: 2's complement of COMP fileds

Postby Robert Sample » Wed Feb 02, 2011 3:55 pm

BillyBoyo,
though COBOL will always resevere space on a half-word boundary for binary fields, you can't necessarily "use" all that space.
is not always true. There is a COBOL compile option, TRUNC, which allows COBOL to ignore the PICTURE size and use the full set of binary values for COMP variables. This option has been around for a number of years.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: 2's complement of COMP fileds

Postby BillyBoyo » Wed Feb 02, 2011 4:40 pm

Robert Sample wrote:BillyBoyo,though COBOL will always resevere space on a half-word boundary for binary fields, you can't necessarily "use" all that space. is not always true. There is a COBOL compile option, TRUNC, which allows COBOL to ignore the PICTURE size and use the full set of binary values for COMP variables. This option has been around for a number of years.


Sorry, wife was coming so had to cut short...

I think it is NOTRUNC (non-standard truncation) which allows full use of the storage allocated, regardless of picture size (can affect all COMP-3 as well). TRUNC, or the standard truncation, generates extra code in the program to ensure that only the maximum values can be used by the program code.

I guess we could read-up in the manual.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: 2's complement of COMP fileds

Postby Robert Sample » Wed Feb 02, 2011 6:12 pm

The COBOL Programming Guide gives the details:
TRUNC has no effect on COMP-5 data items; COMP-5 items are handled as if TRUNC(BIN) were in effect regardless of the TRUNC suboption specified.


TRUNC(STD)
TRUNC(STD) applies only to USAGE BINARY receiving fields in MOVE statements and arithmetic expressions. When TRUNC(STD) is in effect, the final result of an arithmetic expression, or the sending field in the MOVE statement, is truncated to the number of digits in the PICTURE clause of the BINARY receiving field.

TRUNC(OPT)
TRUNC(OPT) is a performance option. When TRUNC(OPT) is in effect, the compiler assumes that data conforms to PICTURE specifications in USAGE BINARY receiving fields in MOVE statements and arithmetic expressions. The results are manipulated in the most optimal way, either truncating to the number of digits in the PICTURE clause, or to the size of the binary field in storage (halfword, fullword, or doubleword).

Tips:

Use the TRUNC(OPT) option only if you are sure that the data being moved into the binary areas will not have a value with larger precision than that defined by the PICTURE clause for the binary item. Otherwise, unpredictable results could occur. This truncation is performed in the most efficient manner possible; therefore, the results are dependent on the particular code sequence generated. It is not possible to predict the truncation without seeing the code sequence generated for a particular statement.

There are some cases when programs compiled with the TRUNC(OPT) option under Enterprise COBOL could give different results than the same programs compiled under OS/VS COBOL with NOTRUNC. You must actually lose nonzero high-order digits for this difference to appear. For statements where loss of high-order digits might cause a difference in results between Enterprise COBOL and OS/VS COBOL, Enterprise COBOL issues a diagnostic message. If you receive this message, make sure that either the sending items will not contain large numbers or that the receivers are defined with enough digits in the PICTURE clause to handle the largest sending data items.


TRUNC(BIN)
The TRUNC(BIN) option applies to all COBOL language that processes USAGE BINARY data. When TRUNC(BIN) is in effect, all binary items (USAGE COMP, COMP-4, or BINARY) are handled as native hardware binary items, that is, as if they were each individually declared USAGE COMP-5:

BINARY receiving fields are truncated only at halfword, fullword, or doubleword boundaries.

BINARY sending fields are handled as halfwords, fullwords, or doublewords when the receiver is numeric; TRUNC(BIN) has no effect when the receiver is not numeric.

The full binary content of fields is significant.

DISPLAY will convert the entire content of binary fields with no truncation.


Recommendations: TRUNC(BIN) is the recommended option for programs that use binary values set by other products. Other products, such as IMS, DB2, C/C++, FORTRAN, and PL/I, might place values in COBOL binary data items that do not conform to the PICTURE clause of the data items. You can use TRUNC(OPT) with CICS programs as long as your data conforms to the PICTURE clause for your BINARY data items.

USAGE COMP-5 has the effect of applying TRUNC(BIN) behavior to individual data items. Therefore, you can avoid the performance overhead of using TRUNC(BIN) for every binary data item by specifying COMP-5 on only some of the binary data items, such as those data items that are passed to non-COBOL programs or other products and subsystems. The use of COMP-5 is not affected by the TRUNC suboption in effect.

Large literals in VALUE clauses: When you use the compiler option TRUNC(BIN), numeric literals specified in VALUE clauses for binary data items (COMP, COMP-4, or BINARY) can generally contain a value of magnitude up to the capacity of the native binary representation (2, 4, or 8 bytes) rather than being limited to the value implied by the number of 9s in the PICTURE clause.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Next

Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post