Fujitsu COBOL and NOTRUNC option

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

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.

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 ?

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.

"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

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.

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.

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

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 an
d
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.
>

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 ?