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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

TRUNC(OPT) 2

Status
Not open for further replies.

MarcLodge

Programmer
Feb 26, 2002
1,886
GB
Hi All,
I have a Cobol subroutine called and running under CICS. It has been compiled using Xpediter and conforms to 'COBOL for OS/390 & VM RELEASE 2.2'. The compilation option of TRUNC(OPT) is in effect.

I know that with this option, the onus is on the programmer to ensure that the value of the data conforms to the size of the field, but what do we think should happen in the following scenarios:
PIC 9(10) VALUE 1234567890 moved to PIC S9(8) BINARY.
PIC 9(10) VALUE 1234567890 moved to PIC S9(9) BINARY.

The use of the word BINARY, rather than COMP-5 appears to be a site standard, so I am unable to use it.

Marc
 
Having compiled and run this in xpediter, I've come up with the answer:Truncation occurs. I'm now at a loss to see where the difference is between TRUNC(OPT) and TRUNC(STD)!
 
Marc:
I looked in an IBM COBOL Programming Guide for the answer. The manual is for COBOL for MVS but I think it works the same. This is a little confusing but here is their example.

The decimal value to move is 123451
The BINARY field is defined as S9(02).

The book says that the TRUNC(OPT) option does its truncation at the most optimal time. It may truncate the original sending value or it may truncate it after doing some conversions before finally filling in the receiving field.

123451 in hex is 00 01 E2 3B
When you use TRUNC(STD) the compiler recognizes you only have two digits in your receiving field, so in effect it truncates the sending field to 51 (as you might expect from your prior test).

Now if you use TRUNC(OPT) the results are entirely different. Look back at the hex value for your sending field. With this option it appears to save the rightmost 2 bytes of the hex value - that would be E2 3B. That value has a '1' in the leftmost bit so appears to be a negative number. It is equivalent to the decimal value -7621. When that is moved to your BINARY field, you end up with -21 in the BINARY field.

I tried it and it does come out this way. I get a warning message when compiling with TRUNC(OPT) telling me I may have a problem.
 
See:


and


for examples of what the various TRUNC options do.

I can't remember which release it was introduce in, but also look at/for the DIAGTRUNC compiler option. See:


Finally, as far as the fields that CICS *itself* "plays with" see the statement at:


which says,

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

which is DIFFERENT from what older documentation said.



Bill Klein
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top