Cobol - Fujitsu COBOL and NOTRUNC option

Author

Fujitsu COBOL and NOTRUNC option

Michael Potter

2004-08-23, 8:55 pm

I would like to gather programmer's experiences using the Fujitsu
COBOL compiler's NOTRUNC compile option. In particular I would like
sample code of unexpected behavior.

Thanks,
Michael Potter

Robert Wagner

2004-08-24, 3:55 am

On 23 Aug 2004 13:41:44 -0700, pottmi@yahoo.com (Michael Potter)
wrote:

>I would like to gather programmer's experiences using the Fujitsu
>COBOL compiler's NOTRUNC compile option. In particular I would like
>sample code of unexpected behavior.

The only difference I've seen is faster execution .. on the order of
2%, more with OPTIMIZE.

The Standard doesn't guarantee portability of BINARY across platforms,
so you shouldn't be writing them to files. At issue is temporary
variables in memory. Hypothetically, a different compiler or options
(TRUNC, OPTIMIZE, MLBOFF) could produce different results. IMO, code
that depends on compiler truncation to produce correct results is
poorly written and likely to contain other fuzzy thinking.

It would be nice if there were a compiler option similar to bounds
checking to diagnose truncation. Unfortunately, there isn't.

Richard

2004-08-24, 3:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> It would be nice if there were a compiler option similar to bounds
> checking to diagnose truncation. Unfortunately, there isn't.

Haven't you heard of ON SIZE ERROR ?

Robert Wagner

2004-08-24, 3:55 am

On 23 Aug 2004 23:10:21 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
>Haven't you heard of ON SIZE ERROR ?

It has to be coded on each statement individually, might require the
addition of END-arithmetic to avoid breaking conditionals, and is not
available on MOVE. Are we to convert 'move a to b' into 'compute b =
a on size error ..'?

After reading the manual, it appears Fujitsu does have the desired
compiler option in CHECK NUMERIC. The manual says it tests "whether
the value matching the attribute format is contained in the numeric
data item". Sounds like truncation would fail that test.

Chuck Stevens

2004-08-26, 3:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:fk7li0l9ihk54655suvmohup8edrdijuqq@
4ax.com...

> The only difference I've seen is faster execution .. on the order of
> 2%, more with OPTIMIZE.

Having only passing exposure to Fujitsu COBOL, but having followed many
discussions in this group about it, what I would expect the value of
01 A-FIELD PIC 999 BINARY VALUE 999.
to be after
ADD 1 TO A-FIELD.
is 1000 if NOTRUNC is set and zero if NOTRUNC is not set.

-Chuck Stevens

Michael Potter

2004-08-26, 3:55 pm

Here is my single sample that i found interesting. what makes this
sample interesting is that a move pic9(8) -> pic9(4) -> pic9(8) works
like a move pic9(8) -> pic9(8).

I am just the guy who is porting code from a mainframe to fujitsu. I
am hoping to find a way to either support the code as is, or find a
change to the source that i can make with a perl script to make it
work. if the change to the source is by hand, then i will probably
give up on using fujitsu. the code relies on the the mainframe
compile option TRUNC(BIN).

[[pottmi@lidp23]]/apex/pottmi/cobtst/truncfuj2>
# ksh ./runme.ksh
STATISTICS: HIGHEST SEVERITY CODE=I, PROGRAM UNIT=1
x-9999-comp 12345679
x-9999-comp3 00005679
x-9999-comp5 12345679
[[pottmi@lidp23]]/apex/pottmi/cobtst/truncfuj2>
# cat ./runme.ksh
#!/bin/ksh

cobol -otrunctst -WC,NOOPT -WC,NOTRUNC -WC,"BINARY(BYTE)" trunctst.cbl

../trunctst

exit 0
[[pottmi@lidp23]]/apex/pottmi/cobtst/truncfuj2>
# cat ./trunctst.cbl
identification division.
program-id. main.

*-
*- This program demonstrates the trunc/notrunc feature
*- of the Fujitsu COBOL compiler.
*-

environment division.

configuration section.
source-computer. ibm-370.
object-computer. ibm-370.
input-output section.
file-control.

data division.
file section.
working-storage section.

01 display-me pic 9(8) comp.

01 x-comp comp.
05 x-99999999-comp pic 9(8).
05 x-9999-comp pic 9(4).

01 x-comp3 comp-3.
05 x-99999999-comp3 pic 9(8).
05 x-9999-comp3 pic 9(4).

01 x-comp5 comp-5.
05 x-99999999-comp5 pic 9(8).
05 x-9999-comp5 pic 9(4).

procedure division.
very-first section.
start-here.

move 12345678 to x-99999999-comp
move x-99999999-comp to x-9999-comp
add 1 to x-9999-comp
move x-9999-comp to display-me
display "x-9999-comp " display-me

move 12345678 to x-99999999-comp3
move x-99999999-comp3 to x-9999-comp3
add 1 to x-9999-comp3
move x-9999-comp3 to display-me
display "x-9999-comp3 " display-me

move 12345678 to x-99999999-comp5
move x-99999999-comp5 to x-9999-comp5
add 1 to x-9999-comp5
move x-9999-comp5 to display-me
display "x-9999-comp5 " display-me

stop run.

Richard

2004-08-26, 3:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
> It has to be coded on each statement individually, might require the
> addition of END-arithmetic to avoid breaking conditionals,

You had written:
""IMO, code that depends on compiler truncation to produce correct
results is poorly written and likely to contain other fuzzy
thinking.""

If you want to 'depend on compiler truncation' then ON SIZE ERROR is
the tool to do this.

> and is not
> available on MOVE. Are we to convert 'move a to b' into 'compute b =
> a on size error ..'?

No, if you want to 'depend on truncation' then use ADD ZERO A GIVING B
ON SIZE ERROR .... END-ADD. COMPUTE uses an intermediate value which
may, or may not, limit the accuracy of the result in b.

> After reading the manual, it appears Fujitsu does have the desired
> compiler option in CHECK NUMERIC. The manual says it tests "whether
> the value matching the attribute format is contained in the numeric
> data item". Sounds like truncation would fail that test.

You will most likely find that this is _not_ what you assume it to be.
It does an equivalent of an IF NUMERIC test, exactly as the manual
states.

For example:

01 Ax.
03 An PIC 9(4).

MOVE "00:0" TO Ax
ADD 1 TO An
DISPLAY An

Result displays -> 00:1

Add CHECK(NUMERIC) and the program fails on the ADD.

It has nothing to do with truncation.

Richard

2004-08-26, 3:55 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote

> Having only passing exposure to Fujitsu COBOL, but having followed many
> discussions in this group about it, what I would expect the value of
> 01 A-FIELD PIC 999 BINARY VALUE 999.
> to be after
> ADD 1 TO A-FIELD.
> is 1000 if NOTRUNC is set and zero if NOTRUNC is not set.

Yes, that is true with the version that I use. If ON SIZE ERROR is
specified then the result in either case is 999 as the branch is taken
and the result is not stored.

William M. Klein

2004-08-26, 3:55 pm

If you want a "portable" and STANDARD solution (from Fujitsu), contact the
vendor and ask them when they plan on providing support for the detection and
appropriate declaratives for handling the

EC-SIZE-TRUNCATION

exception condition.

See page 400 of the 2002 Standard for when this condition is raised

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:fk7li0l9ihk54655suvmohup8edrdijuqq@
4ax.com...
> On 23 Aug 2004 13:41:44 -0700, pottmi@yahoo.com (Michael Potter)
> wrote:
>
>
> The only difference I've seen is faster execution .. on the order of
> 2%, more with OPTIMIZE.
>
> The Standard doesn't guarantee portability of BINARY across platforms,
> so you shouldn't be writing them to files. At issue is temporary
> variables in memory. Hypothetically, a different compiler or options
> (TRUNC, OPTIMIZE, MLBOFF) could produce different results. IMO, code
> that depends on compiler truncation to produce correct results is
> poorly written and likely to contain other fuzzy thinking.
>
> It would be nice if there were a compiler option similar to bounds
> checking to diagnose truncation. Unfortunately, there isn't.
>

Richard

2004-08-26, 3:55 pm

pottmi@yahoo.com (Michael Potter) wrote

> Here is my single sample that i found interesting. what makes this
> sample interesting is that a move pic9(8) -> pic9(4) -> pic9(8) works
> like a move pic9(8) -> pic9(8).

That will depend on what size a COMP-~ field is set to. When I try
your code with the options that you gave I get answers of

x-9999-comp 00024911
x-9999-comp3 00005679
x-9999-comp5 00024911

which implies that the version I use is making a 9(4) COMP-~ as a 2
byte integer.

This is Fujitsu NetCobol for Linux. As a complete guess I would think
you are using Sun and are getting a 4 byte integer for 9(4) COMP-~.

> the code relies on the the mainframe compile option TRUNC(BIN).

So what results did you require ? and why ?

Robert Wagner

2004-08-26, 3:55 pm

On Tue, 24 Aug 2004 09:47:31 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:fk7li0l9ihk54655suvmohup8edrdijuqq@
4ax.com...
>
>
>Having only passing exposure to Fujitsu COBOL, but having followed many
>discussions in this group about it, what I would expect the value of
> 01 A-FIELD PIC 999 BINARY VALUE 999.
>to be after
> ADD 1 TO A-FIELD.
>is 1000 if NOTRUNC is set and zero if NOTRUNC is not set.

That's right. The extra instruction to left-truncate explains the
speed difference.

Robert Wagner

2004-08-26, 3:55 pm

On 24 Aug 2004 12:00:09 -0700, pottmi@yahoo.com (Michael Potter)
wrote:

>Here is my single sample that i found interesting. what makes this
>sample interesting is that a move pic9(8) -> pic9(4) -> pic9(8) works
>like a move pic9(8) -> pic9(8).
>
>I am just the guy who is porting code from a mainframe to fujitsu. I
>am hoping to find a way to either support the code as is, or find a
>change to the source that i can make with a perl script to make it
>work. if the change to the source is by hand, then i will probably
>give up on using fujitsu. the code relies on the the mainframe
>compile option TRUNC(BIN).

These are made-up cases. In the real world, programs will probably
never 'rely' on compiler truncation.

Verify that CHECK NUMERIC reports truncation. Assuming it does,
compile with that option and run your programs with a LARGE SAMPLE of
real data. If no truncations are occurring, TRUNC is not necessary. It
will run the same with or without.

If truncation is occurring, it's probably on one or two lines of code.
Fix the source logic or simply compile those programs with TRUNC.

The speed difference isn't worth getting lathered up over.

Robert Wagner

2004-08-26, 3:55 pm

On 24 Aug 2004 12:50:31 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
>You had written:
>""IMO, code that depends on compiler truncation to produce correct
>results is poorly written and likely to contain other fuzzy
>thinking.""
>
>If you want to 'depend on compiler truncation' then ON SIZE ERROR is
>the tool to do this.

The question was whether turning off compiler truncation would cause
an existing program to act differently. I was looking for a way to
test that by running the program both ways. I don't want to depend on
compiler truncation, I want to determine whether someone else is.

>
>No, if you want to 'depend on truncation' then use ADD ZERO A GIVING B
>ON SIZE ERROR .... END-ADD. COMPUTE uses an intermediate value which
>may, or may not, limit the accuracy of the result in b.

The standard doesn't require an intermediate value. A smart compiler
would generate the same code for COMPUTE B=A and MOVE A TO B. Compute
may look strange in Cobol but in other languages that form is
commonplace assignment.

>
>You will most likely find that this is _not_ what you assume it to be.
> It does an equivalent of an IF NUMERIC test, exactly as the manual
>states.

That's what I thought at first glance. The manual does NOT say a
numeric test is performed. It says "matching the attribute format".
What does that mean? I interpret it to mean 123 does not match the
format pic 99.

Richard

2004-08-26, 3:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> The standard doesn't require an intermediate value. A smart compiler
> would generate the same code for COMPUTE B=A and MOVE A TO B. Compute
> may look strange in Cobol but in other languages that form is
> commonplace assignment.

COMPUTE _may_ use an intermediate result. The size and precision of
this is implementor defined (last time I looked). This may, or may
not, mean that the COMPUTE gives a result that is not the same as a
MOVE or an ADD. For example if A and B were S9V9(17) and the
intermediate were defined by the implementor as the equivalent of
S9(18)V9(12).

If a 'smart compiler' would generate the same as the MOVE when
optimizing is on, then it may give different results when not
optimizing (for example compiling for debugging may turn optimization
off) or on different compilers or platforms.

Using COMPUTE is _not_ an answer to TRUNC problems.

>
> That's what I thought at first glance. The manual does NOT say a
> numeric test is performed. It says "matching the attribute format".
> What does that mean? I interpret it to mean 123 does not match the
> format pic 99.

Read my lips:

The compiler does the equivalent of an IF NUMERIC test.
It does not check if binary values exceed the picture.
Your 'interpretation' is wrong.

When I said "you will most likely find .." this implied: ".. if you
try it".

When I said "It does ..." this implied: "I tested it and this is what
my version does".

If you want to try it with your own version and find that it does meet
your your interpretation then we may discuss it further.

Chuck Stevens

2004-08-26, 3:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:a4ooi053i5o795uqa347mqdemms2j0m8rg@
4ax.com...

> The standard doesn't require an intermediate value.

In 2002 COBOL by default, and in all previous standards, arithmetic
expression handling rules are pretty much what the implementor defines them
to be, so the above statement is *partly* correct.

However, if ARITHMETIC IS STANDARD is specified in 2002 COBOL (in the
OPTIONS paragraph of the IDENTIFICATION DIVISION), the statement is directly
and explicitly contradicted by the standard.

ISO/IEC 1989:2002 page 121, paragraph 8.8.1.3.1, Standard intermediate data
item, rule 1 states "Any operand of an arithmetic expression that is not
already contained in a standard intermediate data item shall be converted
into a standard intermediate data item", and the associated note essentially
says "Yes, in case you were wondering, this includes COMPUTE A = B".

> A smart compiler would generate the same code for COMPUTE B=A and MOVE A
TO B.

By default (that is, without ON SIZE ERROR) the code for COMPUTE is required
to cause the raising of EC-SIZE-TRUNCATION (a *fatal* exception if not
otherwise handled) if high-order digit truncation actually occurs (ibid.,
page 400, 14.6.4, SIZE ERROR phrase and size error condition, rule 3 under
the heading "If the size error condition exists and a SIZE ERROR phrase is
not specified".

MOVE is required to truncate non-zero high-order digits from the source that
won't fit in the destination, silently and unconditionally, as I see it
(ibid., page 389, 14.5.8, Alignment of data within data items, rule 1, and
page 479, 14.8.24, MOVE statement, general rule 4b).

Thus, for current standard COBOL, I would have to characterize the decision
to generate the same code for both constructs as a *wrong*, rather than
*smart*.

-Chuck Stevens

Robert Wagner

2004-08-26, 3:55 pm

On Wed, 25 Aug 2004 13:38:54 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:a4ooi053i5o795uqa347mqdemms2j0m8rg@
4ax.com...
>
>
>In 2002 COBOL by default, and in all previous standards, arithmetic
>expression handling rules are pretty much what the implementor defines them
>to be, so the above statement is *partly* correct.
>
>However, if ARITHMETIC IS STANDARD is specified in 2002 COBOL (in the
>OPTIONS paragraph of the IDENTIFICATION DIVISION), the statement is directly
>and explicitly contradicted by the standard.
>
>ISO/IEC 1989:2002 page 121, paragraph 8.8.1.3.1, Standard intermediate data
>item, rule 1 states "Any operand of an arithmetic expression that is not
>already contained in a standard intermediate data item shall be converted
>into a standard intermediate data item", and the associated note essentially
>says "Yes, in case you were wondering, this includes COMPUTE A = B".

Soon after a 2002 appears, users will run a timing test and find that
standard arithmetic runs x times slower than regular. Thereafter, they
will avoid it.

>TO B.
>
>By default (that is, without ON SIZE ERROR) the code for COMPUTE is required
>to cause the raising of EC-SIZE-TRUNCATION (a *fatal* exception if not
>otherwise handled) if high-order digit truncation actually occurs (ibid.,
>page 400, 14.6.4, SIZE ERROR phrase and size error condition, rule 3 under
>the heading "If the size error condition exists and a SIZE ERROR phrase is
>not specified".

That might be a backward-compatibility issue. There have been times
when I wanted a remainder and didn't care about the quotient. For
example, to get the day of w

of an integer date. Yes, I know
there's a function for that, but it's faster to say
DIVIDE 7 INTO integer-date GIVING n REMAINDER day-of-w

I didn't pay attention to the size of n because the value was a
discard. If the GIVING clause had been optional, I would have omitted
it.

Under the new rule, those programs are likely to abend.

Chuck Stevens

2004-08-26, 3:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:fkfqi0d0cst8cj3ds9kv42ddgdtqmeqohp@
4ax.com...

> Soon after a 2002 appears, users will run a timing test and find that
> standard arithmetic runs x times slower than regular. Thereafter, they
> will avoid it.

May well be ... *unless and until* some implementor provides a platform that
can support standard arithmetic efficiently.

But I also know of customers who complain bitterly about the
"implementor-defined" nature of arithmetic in COBOL(68), COBOL(74) and
COBOL(85), and who welcome the idea of standardization of behavior in this
area. hardware is inexpensive these days.

> That might be a backward-compatibility issue. There have been times
> when I wanted a remainder and didn't care about the quotient. For
> example, to get the day of w

of an integer date. Yes, I know
> there's a function for that, but it's faster to say
> DIVIDE 7 INTO integer-date GIVING n REMAINDER day-of-w

> I didn't pay attention to the size of n because the value was a
> discard. If the GIVING clause had been optional, I would have omitted
> it.

Red herring. We were discussing only COMPUTE B = A versus MOVE A TO B, and
whether it was appropriate for the compiler to presume they always did the
same thing. '

> Under the new rule, those programs are likely to abend.

I misspoke earlier. The default for exception handling is compatibility
with previous standards; thus, if the TURN directive is not specified, the
default is ">>TURN EC-ALL CHECKING OFF".

I stand by my point, though: a compiler writer *might* cause the compiler
to generate the same code for "COMPUTE B = A" and "MOVE A TO B" under
certain circumstances, but I would suggest that for the compiler programmer
to presume that it was *always* appropriate to do so would be a Big Mistake.

Certainly "COMPUTE B, C, D, E = A" and "MOVE A TO B, C, D, E" should be
expected to generate different code except under *very* specific and limited
circumstances, and the single-destination case is but a subset of this.

-Chuck Stevens

Richard

2004-08-27, 3:55 pm

Robert Wagner

2004-08-31, 3:55 am

Chuck Stevens

2004-08-31, 3:55 pm

Michael Potter

2004-08-31, 3:55 pm

Richard

2004-08-31, 3:55 pm

Richard

2004-08-31, 3:55 pm

Robert Wagner

2004-08-31, 8:55 pm

of an integer date. Yes, I know
there's a function for that, but it's faster to say
DIVIDE 7 INTO integer-date GIVING n REMAINDER day-of-w

I didn't pay attention to the size of n because the value was a
discard. If the GIVING clause had been optional, I would have omitted
it.

Under the new rule, those programs are likely to abend.

William M. Klein

2004-09-01, 3:55 am

Robert Wagner

2004-09-01, 3:55 am

Robert Wagner

2004-09-01, 3:55 am

Sponsored Links