Home > Archive > Cobol > November 2007 > TRUNC(BIN) and COMP-5
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
TRUNC(BIN) and COMP-5
|
|
| William M. Klein 2007-10-27, 6:55 pm |
| I realized that I made one mistake in my reply to RW.
COMP-5 and COMP with TRUNC(BIN) perform identically. The advantage of COMP-5 is
that you can use the TRUNC(OPT) compiler option which will impact all "normal"
COMP and BINARY fields. You only need to use COMP-5 for fields that MAY contain
data larger than the picture clause. (All of this applies to IBM Enterprise
COBOL - any release and NOT to COMP-5 in other implementations).
To summarize,
For IBM Enterprise COBOL, COMP-5 is a "content of field" USAGE and is not
documented as a "performance" USAGE. It is documented as SLOWER than using
COMP/BINARY with TRUNC(OPT) in most cases. See:
http://publibz.boulder.ibm.com/cgi-...igy3pg32/2.4.54
which states,
"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. "
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Michael Mattias 2007-10-28, 6:55 pm |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:mPOUi.263404$zt4.170346@fe08.news.easynews.com...
>I realized that I made one mistake in my reply to RW.
>
> COMP-5 and COMP with TRUNC(BIN) perform identically. The advantage of
> COMP-5 is ....
If I may introduce an observation here...
If one is relying on the specific performance of TRUNC(), does that not
suggest one is catering to overflow, which further suggests the offending
code should be reworked to avoid overflowing both primary and intermediate
results or at the very least be handled with an ON SIZE ERROR clause?
Inquiring Minds Want to Know!
--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmattias@talsystems.com
| |
| Judson McClendon 2007-10-28, 6:55 pm |
| "Michael Mattias" <mmattias@talsystems.com> wrote:
>
> If one is relying on the specific performance of TRUNC(), does that not suggest one is catering to overflow, which further
> suggests the offending code should be reworked to avoid overflowing both primary and intermediate results or at the very least be
> handled with an ON SIZE ERROR clause?
I have written algorithms that specifically depended on truncation. When you
choose the receiving data type correctly, it can be 'cheaper' than division with
a remainder. Example: stripping off the units digit of a number.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Robert 2007-10-28, 6:55 pm |
| On Sat, 27 Oct 2007 22:18:58 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>I realized that I made one mistake in my reply to RW.
>
>COMP-5 and COMP with TRUNC(BIN) perform identically. The advantage of COMP-5 is
>that you can use the TRUNC(OPT) compiler option which will impact all "normal"
>COMP and BINARY fields. You only need to use COMP-5 for fields that MAY contain
>data larger than the picture clause. (All of this applies to IBM Enterprise
>COBOL - any release and NOT to COMP-5 in other implementations).
>
>To summarize,
> For IBM Enterprise COBOL, COMP-5 is a "content of field" USAGE and is not
>documented as a "performance" USAGE. It is documented as SLOWER than using
>COMP/BINARY with TRUNC(OPT) in most cases. See:
>
>http://publibz.boulder.ibm.com/cgi-...igy3pg32/2.4.54
>
>which states,
>
>"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. "
I naively thought THE MACHINE would be used to truncate a value to word size. For example,
I thought ADD A B GIVING C would generate
L R5,A
A R5,B
ST R5,C
Evidently, IBM has to call a function to insure a 32 bit register doesn't contain more
than 32 bits of data. :) They COULD have done it with an inline
N R5,=X'FFFFFFFF' Do nothing instruction
Further adding to the mystery, this example says TRUNC(OPT) turns the mainframe into a
little-endian machine.
http://tinyurl.com/yt62pa
| |
| William M. Klein 2007-10-28, 6:55 pm |
| As I have said before, anyone (RW especially <G> ) who ASSUMES that they know
what code is generated by a compiler is likely to make mistakes about the
performance of specific (COBOL) code sequences and features.
There is a "relatively" long history behind the types of code generated for
COMP, BINARY, and various TRUNC options. Certainly IBM's customers are QUITE
happy with the fact that TRUNCIOPT) with COMP fields is the "best performing"
combination - as this DOES allow for the majority of "legacy" code to perform
well.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:ghd9i31ouuucrujojivbmm8e24bo7cgee4@
4ax.com...
> On Sat, 27 Oct 2007 22:18:58 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> I naively thought THE MACHINE would be used to truncate a value to word size.
> For example,
> I thought ADD A B GIVING C would generate
>
> L R5,A
> A R5,B
> ST R5,C
>
> Evidently, IBM has to call a function to insure a 32 bit register doesn't
> contain more
> than 32 bits of data. :) They COULD have done it with an inline
>
> N R5,=X'FFFFFFFF' Do nothing instruction
>
> Further adding to the mystery, this example says TRUNC(OPT) turns the
> mainframe into a
> little-endian machine.
>
> http://tinyurl.com/yt62pa
| |
| William M. Klein 2007-10-28, 6:55 pm |
| It is (sort-of) this issue that explains why TRUNC(OPT) is the best performing
setting. With this setting, when you have "valid" (fits PICTURE) data *and*
your operations either produce "valid" data or use ON SIZE ERROR phrases, then
the compiler can create the "best" code. TRUNC(STD) and TRUNC(BIN) both require
the compile to produce code that DOES deal with "over-sized" contents and take
"appropriate" action.
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:SU%Ui.17492$JD.3736@newssvr21.news.prodigy.net...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:mPOUi.263404$zt4.170346@fe08.news.easynews.com...
>
> If I may introduce an observation here...
>
> If one is relying on the specific performance of TRUNC(), does that not
> suggest one is catering to overflow, which further suggests the offending code
> should be reworked to avoid overflowing both primary and intermediate results
> or at the very least be handled with an ON SIZE ERROR clause?
>
> Inquiring Minds Want to Know!
>
> --
> Michael C. Mattias
> Tal Systems Inc.
> Racine WI
> mmattias@talsystems.com
>
>
>
| |
| Sergey Kashyrin 2007-10-29, 6:55 pm |
| > Further adding to the mystery, this example says TRUNC(OPT) turns the
> mainframe into a
> little-endian machine.
:-))
They are simply wrong.
"Robert" <no@e.mail> wrote in message
news:ghd9i31ouuucrujojivbmm8e24bo7cgee4@
4ax.com...
> On Sat, 27 Oct 2007 22:18:58 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> I naively thought THE MACHINE would be used to truncate a value to word
> size. For example,
> I thought ADD A B GIVING C would generate
>
> L R5,A
> A R5,B
> ST R5,C
>
> Evidently, IBM has to call a function to insure a 32 bit register doesn't
> contain more
> than 32 bits of data. :) They COULD have done it with an inline
>
> N R5,=X'FFFFFFFF' Do nothing instruction
>
> Further adding to the mystery, this example says TRUNC(OPT) turns the
> mainframe into a
> little-endian machine.
>
> http://tinyurl.com/yt62pa
| |
| William M. Klein 2007-10-29, 6:55 pm |
| "Robert" <no@e.mail> wrote in message
news:ghd9i31ouuucrujojivbmm8e24bo7cgee4@
4ax.com...
> On Sat, 27 Oct 2007 22:18:58 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
<snip>
> Further adding to the mystery, this example says TRUNC(OPT) turns the
> mainframe into a
> little-endian machine.
>
> http://tinyurl.com/yt62pa
Correction now sent to the IBM dox folks. Thanks for pointing it out.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
|
|
|
|
|