TRUNC COBOL compiler option behaves differently.

[Priya Padma]

Hello fellow members,

There is a discussion going on at our site about 'TRUNC' COBOL compiler option. Some said, we should change from TRUNC(STD) to TRUNC(BIN) for all batch-programs. Though we already using TRUNC(BIN) setup for CICS COBOL programs. Nothing is final but discussion are on.

I read about TRUNC online and did a small experiment around it which follows:

Default is: TRUNC(STD)

Abbreviations are: None

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).

Tip: 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.
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 DB2, C/C++, 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.

Please consider the following cases:

Code: Select all

  WS-VOLATILE-LENGTH    	PIC 9(5).
  WS-RANDOM-VARIABLE   		PIC X(3000).
**
  WS-LENGTH-8000   		PIC 9(5) VALUE 8000.
**
  WS-TOTAL-LENGTH 		PIC S9(4) COMP. 
**  

Now see the following two codes:

1. Code: Select all

   COMPUTE WS-TOTAL-LENGTH = WS-LENGTH-8000 + LENGTH OF WS-RANDOM-VARIABLE

   OUTPUT:
   

   Code: Select all

   WS-TOTAL-LENGTH = 1000

2. Code: Select all

   MOVE LENGTH OF WS-RANDOM-VARIABLE TO WS-VOLATILE-LENGTH
   COMPUTE WS-TOTAL-LENGTH = WS-LENGTH-8000 + WS-VOLATILE-LENGTH
   

   OUTPUT:
   

   Code: Select all

   WS-TOTAL-LENGTH = 11000

I have used the compiler option is TRUNC(OPT). Why in the heaven, there is no truncation for part 2?

[Robert Sample]

You answered your own question in your post:

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).

One of the dangers in using TRUNC(OPT) is that you do not know, in any given case, whether the truncation will be to the PICTURE size or to the size of the binary field. You have found one of the cases where truncation to the binary field size occurred. The quote you gave states categorically that it is not possible to predict the truncation unless you look at the code generated.

[William Collins]

What is the reason you want to use TRUNC(BIN) in batch? What is the reason you already use TRUNC(BIN) in CICS?