Hello,

I have a field
     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
I am trying to convert it to unpacked field
     04 FIELD-B                 PIC S9(10)V9(5).

I am doing
        ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.

The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
How to get correct value in FIELD-B?

Debug trace for your reference

-UNPAKDAT-D FIELD-A
FIELD-A =          +0.00010
-UNPAKDAT-D FIELD-B
FIELD-B =        100.00000


note: Sorry, I wrote mult of 1000. It was the case for a different
value of FIELD-A

In article <85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>, ChinmaYT <chinmay13@gmail.com> wrote:
>Hello,
>
>I have a field
>     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>I am trying to convert it to unpacked field
>     04 FIELD-B                 PIC S9(10)V9(5).
>
>I am doing
>        ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.

Why??

Either MOVE FIELD-A TO FIELD-B or COMPUTE FIELD-B = FIELD-A is *much* simpler.
>
>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>How to get correct value in FIELD-B?

I think that either you're misunderstanding what you see in FIELD-B, or you 
haven't reproduced the field definitions correctly. Please post a 
copy-and-paste of the _actual_ code in both the Data and Procedure divisions.

Also, recompile the program using the directives ?CODE,ICODE,INNERLIST and 
post the assembly-language instructions that correspond to the Cobol MOVE 
instruction.

On Dec 15, 9:47=A0am, spamb...@milmac.com (Doug Miller) wrote:
> In article <85416422-38fc-4916-9a71-083e0aa8f...@f16g2000yqm.googlegroups=
..com>, ChinmaYT <chinma...@gmail.com> wrote:

> Also, recompile the program using the directives ?CODE,ICODE,INNERLIST an=
d
> post the assembly-language instructions that correspond to the Cobol MOVE
> instruction.

I look forward to seeing this post!  Thanks for the chuckle.

In article <8ceb2306-9177-47ce-bf63-c7b2701b29bd@u7g2000yqm.googlegroups.com>, mustlearntandem <mustlearntandem@netscape.net> wrote:
>On Dec 15, 9:47=A0am, spamb...@milmac.com (Doug Miller) wrote:
>> In article <85416422-38fc-4916-9a71-083e0aa8f...@f16g2000yqm.googlegroups=
>..com>, ChinmaYT <chinma...@gmail.com> wrote:
>
>> Also, recompile the program using the directives ?CODE,ICODE,INNERLIST and
>> post the assembly-language instructions that correspond to the Cobol MOVE
>> instruction.
>
>I look forward to seeing this post!  Thanks for the chuckle.

Not sure what you mean... why the chuckle?

On Dec 15, 11:37=A0am, spamb...@milmac.com (Doug Miller) wrote:
> In article <8ceb2306-9177-47ce-bf63-c7b2701b2...@u7g2000yqm.googlegroups.=
com>, mustlearntandem <mustlearntan...@netscape.net> wrote:
>
> >On Dec 15, 9:47=3DA0am, spamb...@milmac.com (Doug Miller) wrote:
> >> In article <85416422-38fc-4916-9a71-083e0aa8f...@f16g2000yqm.googlegro=
ups=3D
> >..com>, ChinmaYT <chinma...@gmail.com> wrote:
>
> >> Also, recompile the program using the directives ?CODE,ICODE,INNERLIST=
 and
> >> post the assembly-language instructions that correspond to the Cobol M=
OVE
> >> instruction.
>
> >I look forward to seeing this post! =A0Thanks for the chuckle.
>
> Not sure what you mean... why the chuckle?

Because a programmer who demonstrates beginner knowledge of COBOL is
likely to be clueless when it comes to generating and then locating
assembly language instructions that correspond to specific COBOL
statements.

ChinmaYT wrote:
> I have a field
>      04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
> I am trying to convert it to unpacked field
>      04 FIELD-B                 PIC S9(10)V9(5).
> 
> I am doing
>         ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
> 
> The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
> How to get correct value in FIELD-B?
> 
> Debug trace for your reference
> 
> -UNPAKDAT-D FIELD-A
> FIELD-A =          +0.00010
> -UNPAKDAT-D FIELD-B
> FIELD-B =        100.00000
> 
> 
> note: Sorry, I wrote mult of 1000. It was the case for a different
> value of FIELD-A

(I combined your two posts)

I assume you are using native COBOL on a G-series system.  If not, what are you using?

I agree with Doug that using a MOVE would be a more natural way to convert that field, but I assume you had some reason for doing it the indirect way using ADD rather than a simple MOVE.  If you originally used MOVE, found it did not work, and tried ADD as a work around, did the behaviour change at all?

Doug's suggestion to show us the code generated for the ADD (or MOVE if you change to use that) is good, too, if you know how to do that.

It seems a little odd that the Inspect display of FIELD-A shows a + sign, but the display of FIELD-B does not show a + sign.  Did you show us the correct declaration for FIELD-B?  Is it signed or unsigned?  I do not remember whether Inspect shows a sign for positive signed display numeric fields or not.  Maybe it does the display for COMP-3 differently than for ordinary display numeric fields.

It seems that you are saying that the factor by which the result differs from what it should be is different for different values in FIELD-A.  That surprises me.  Is that really what is happening, or did I misunderstand what you wrote?  If it really is happening that way, can you tell us some more values and the incorrect results?

One thing I would do is look at the raw data in FIELD-A to see whether it is being interpreted correctly.  I believe the command

   D FIELD-A IN HEX

might do that.  If that does not seem to work, I would try

   D FIELD-A WHOLE IN HEX

but I am not certain that would work, either.  I see that FIELD-A is within a group.  I am pretty sure that the command

   D group-name WHOLE IN HEX

will display the data as I would want to see it, but it would display all of the data in the group without showing you where each elementary item is within the group.  You would have to determine how many bytes from the start of the group FIELD-A starts, and look at the 8 bytes starting there.  I believe INFO IDENTIFIER will tell you the offset of the field from the start of the group.

The way that is sure to work is to determine the address of FIELD-A, then switch to low-level Inspect and display 8 bytes of data in hex at that address.  The command

   INFO IDENTIFIER FIELD-A

will give the location of the data, but perhaps not the absolute address.  You may have to add a stack frame address or find the address of the group item and add it or something.  I just do not remember what you must do to find the address of a COBOL data item.  If you are not very familiar with working with low-level Inspect, perhaps you should not try this since I cannot remember enough about how it works to give you the exact commands.

If you manage to display the contents of FIELD-A in hex, then examine it to see whether the value is being interpreted correctly.  The layout for COMP-3 data is described in the COBOL manual in chapter 7 "Data Division" under "Descriptions of Records" under "USAGE clause".

I think it is unlikely that Inspect is misinterpreting the value of FIELD-B, but if you do figure out how to display the value of FIELD-A in hex, look at FIELD-B in hex, too, just to be sure.  (I think FIELD-B is 15 bytes, but check with INFO IDENTIFIER to be sure.)

If Inspect is properly interpreting the COMP-3 data, or you cannot figure out how to display the hex values, then we have to look further for the reason for the problem.

Another thing you could try is make a small test program that contains only the two fields and the ADD statement you showed in your post, plus enough other COBOL statements to make a complete program and initialize the value of FIELD-A.  Then see whether the small test has the same problem.  If the small test does not have the problem, maybe the compiler is making a mistake when compiling your large program or perhaps there is a logic error in your program and it is accidently overwriting data.  (But if you did the two Inspect DISPLAY commands immediately after the ADD statement, overwriting your data seems an unlikely explanation.)

Something that often happens in TAL and C programs that were compiled with optimization is that a result does not get stored into a data item if it is only used immediately in another expression and never used again, or the store into the data item is delayed and your Inspect DISPLAY command shows an old value, before the new result gets stored.  I have a feeling that, given the field descriptions you show, this would not be happening in your program, but if it would be easy for you to recompile the program with OPTIMIZE 0, it probably would be worth trying that to see whether it makes a difference.  If that fixes the problem, then the likely explanation is that Inspect's display of FIELD-B was displaying a value that was not up-to-date due to optimization, but it could mean that the compiler made a mistake when optimizing the code.

Another thing you could try is to put a COBOL DISPLAY statement right after the ADD and have it display both FIELD-A and FIELD-B.  If the problem is either optimization or that Inspect is misinterpreting the COMP-3 field, the COBOL DISPLAY should show the correct values.  If the problem is that COBOL is misinterpreting the COMP-3 value, then this would still show the wrong value in FIELD-B.

One more experiement I would try is to remove the ROUNDED option from the ADD, just in case that is causing it to compile incorrectly or the rounding is done incorrectly.

That is all I can think of to suggest at the moment.  If these suggestions let you figure out what the problem is and you can correct it, good.  If you still cannot figure out what is wrong, post again with a description of what you tried and what results you saw.  Maybe they will suggest other things to try.

In article <addf711f-9561-401b-8e15-e26b8715cc90@e20g2000vbb.googlegroups.com>, mustlearntandem <mustlearntandem@netscape.net> wrote:
>On Dec 15, 11:37=A0am, spamb...@milmac.com (Doug Miller) wrote:
>> In article <8ceb2306-9177-47ce-bf63-c7b2701b2...@u7g2000yqm.googlegroups.=
>com>, mustlearntandem <mustlearntan...@netscape.net> wrote:
>>
>> >On Dec 15, 9:47=3DA0am, spamb...@milmac.com (Doug Miller) wrote:
>> >> In article <85416422-38fc-4916-9a71-083e0aa8f...@f16g2000yqm.googlegro=
>ups=3D
>> >..com>, ChinmaYT <chinma...@gmail.com> wrote:
>>
>> >> Also, recompile the program using the directives ?CODE,ICODE,INNERLIST and
>> >> post the assembly-language instructions that correspond to the Cobol MOVE
>> >> instruction.
>>
>> >I look forward to seeing this post! =A0Thanks for the chuckle.
>>
>> Not sure what you mean... why the chuckle?
>
>Because a programmer who demonstrates beginner knowledge of COBOL is
>likely to be clueless when it comes to generating and then locating
>assembly language instructions that correspond to specific COBOL
>statements.

Actually, it's pretty easy. With ?INNERLIST, the assembly instructions are 
interleaved in the listing with the high-level source instructions they 
correspond to, and even without it -- with only ?CODE, ICODE -- the line 
numbers of the high-level source are printed next to the assembly listing at 
the end.

In article <Z6idncX0HtUGaLrWnZ2dnUVZ_qOdnZ2d@giganews.com>, kdick@acm.org wrote:
>It seems a little odd that the Inspect display of FIELD-A shows a + sign, but
> the display of FIELD-B does not show a + sign.  Did you show us the correct
> declaration for FIELD-B?  Is it signed or unsigned?  I do not remember whether
> Inspect shows a sign for positive signed display numeric fields or not.  Maybe
> it does the display for COMP-3 differently than for ordinary display numeric
> fields.

Keith, I don't believe for one minute that we're seeing a copy-and-paste 
either of actual code or of actual results. I think that if the OP would 
provide us with copies of his _actual_ program and his _actual_ Inspect 
session, the problem would become readily apparent.

On Dec 16, 7:34=A0am, spamb...@milmac.com (Doug Miller) wrote:
> In article <Z6idncX0HtUGaLrWnZ2dnUVZ_qOdn...@giganews.com>, kd...@acm.org=
 wrote:
> >It seems a little odd that the Inspect display of FIELD-A shows a + sign=
, but
> > the display of FIELD-B does not show a + sign. =A0Did you show us the c=
orrect
> > declaration for FIELD-B? =A0Is it signed or unsigned? =A0I do not remem=
ber whether
> > Inspect shows a sign for positive signed display numeric fields or not.=
 =A0Maybe
> > it does the display for COMP-3 differently than for ordinary display nu=
meric
> > fields.
>
> Keith, I don't believe for one minute that we're seeing a copy-and-paste
> either of actual code or of actual results. I think that if the OP would
> provide us with copies of his _actual_ program and his _actual_ Inspect
> session, the problem would become readily apparent.

I am using TNS E and H Searies Tandem System. Also the variable is in
a group and I am reading data from file.
I am unable to paste the whole structure here because of undisclose
policy.


-UNPAKDAT-info identifier FIELD-A
FIELD-A: VARIABLE
storage^info:
TYPE=3DPAK SIGN, ELEMENT LEN=3D4 BITS, UNIT SIZE=3D16 ELEMENTS, SCALE=3D5
access^info:
'L' + 6S WORDS + %213 BYTES
structure^info:
PARENT=3DRECORD-A


-UNPAKDAT-info identifier FIELD-B
FIELD-B: VARIABLE
storage^info:
TYPE=3DNUM TR EM, ELEMENT LEN=3D8 BITS, UNIT SIZE=3D15 ELEMENTS, SCALE=3D5
access^info:
'L' + %21S + %166 WORDS
structure^info:
PARENT=3DRECORD-B

-UNPAKDAT(STEP 1 V)-d FIELD-A
IN-FILE.RECORD-A.FIELD-A =3D          +0.00010

-UNPAKDAT-d FIELD-B
RECORD-B.FIELD-B =3D        100.00000

-UNPAKDAT-d FIELD-A whole in hex
IN-FILE.RECORD-A.FIELD-A =3D 0 0 0 1 0 0 0 %HC

-UNPAKDAT-d FIELD-B whole in hex
RECORD-B.FIELD-B =3D %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H30 %H30
%H30 %H30 %H30 %H30 %H30

The same case happens whatever I try ADD or MOVE or removing ROUNDED
from ADD statement.

I tried to modify the data of FIELD-A (m FIELD-A in debug)with the
same value +0.00010, and after (add/move whatever) it works fine and
correct value is moved.

ChinmaYT wrote:
> On Dec 16, 7:34 am, spamb...@milmac.com (Doug Miller) wrote:
> 
>>In article <Z6idncX0HtUGaLrWnZ2dnUVZ_qOdn...@giganews.com>, kd...@acm.org wrote:
>>
>>>It seems a little odd that the Inspect display of FIELD-A shows a + sign, but
>>>the display of FIELD-B does not show a + sign.  Did you show us the correct
>>>declaration for FIELD-B?  Is it signed or unsigned?  I do not remember whether
>>>Inspect shows a sign for positive signed display numeric fields or not.  Maybe
>>>it does the display for COMP-3 differently than for ordinary display numeric
>>>fields.
>>
>>Keith, I don't believe for one minute that we're seeing a copy-and-paste
>>either of actual code or of actual results. I think that if the OP would
>>provide us with copies of his _actual_ program and his _actual_ Inspect
>>session, the problem would become readily apparent.
> 
> 
> I am using TNS E and H Searies Tandem System. Also the variable is in
> a group and I am reading data from file.
> I am unable to paste the whole structure here because of undisclose
> policy.
> 
> 
> -UNPAKDAT-info identifier FIELD-A
> FIELD-A: VARIABLE
> storage^info:
> TYPE=PAK SIGN, ELEMENT LEN=4 BITS, UNIT SIZE=16 ELEMENTS, SCALE=5
> access^info:
> 'L' + 6S WORDS + %213 BYTES
> structure^info:
> PARENT=RECORD-A
> 
> 
> -UNPAKDAT-info identifier FIELD-B
> FIELD-B: VARIABLE
> storage^info:
> TYPE=NUM TR EM, ELEMENT LEN=8 BITS, UNIT SIZE=15 ELEMENTS, SCALE=5
> access^info:
> 'L' + %21S + %166 WORDS
> structure^info:
> PARENT=RECORD-B
> 
> -UNPAKDAT(STEP 1 V)-d FIELD-A
> IN-FILE.RECORD-A.FIELD-A =          +0.00010
> 
> -UNPAKDAT-d FIELD-B
> RECORD-B.FIELD-B =        100.00000
> 
> -UNPAKDAT-d FIELD-A whole in hex
> IN-FILE.RECORD-A.FIELD-A = 0 0 0 1 0 0 0 %HC
> 
> -UNPAKDAT-d FIELD-B whole in hex
> RECORD-B.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H30 %H30
> %H30 %H30 %H30 %H30 %H30
> 
> The same case happens whatever I try ADD or MOVE or removing ROUNDED
> from ADD statement.
> 
> I tried to modify the data of FIELD-A (m FIELD-A in debug)with the
> same value +0.00010, and after (add/move whatever) it works fine and
> correct value is moved.

Inspect is displaying the value of the comp-3 field incorrectly.  If you look at the hex value for FIELD-A, remembering that each byte encodes two digits and the picture has 5 digits following the implied decimal point, the field contains 00000010000000+ which is 100.  So the value placed into FIELD-B is correct.

I am not sure what you mean when you said you modified FIELD-A in debug to set it to +0.00010 and it worked correctly.  Did you display the value in FIELD-A after modifying it (display it both the regular way and in hex)?  What does that show?

So from what you have shown in this post, COBOL seems to be handling the data correctly.  The problem is that Inspect is displaying the value of the comp-3 field incorrectly.  I believe you should construct a small example program that demonstrates that Inspect displays that value incorrectly and use it to report the Inspect problem to GCSC, or whatever that group is named now.  They should report the problem to Inspect development so they can fix it.

I cannot yet tell whether what you saw upon using Inspect to modify the value of FIELD-A is also an error.  My guess is that it does not show any further problem.  Maybe Inspect can store values into comp-3 fields correctly, but cannot display the values in comp-3 fields correctly.

Until you get a corrected version of Inspect, you should not trust the values Inspect shows for comp-3 fields.  If you must learn the value of a comp-3 field, use the method of displaying it in hex, then interpret the hex digits to figure out what the value is.  

If you want to take time to experiment to see whether Inspect handles some comp-3 fields correctly, try storing 100 into comp-3 fields with different pictures.  Try different numbers of digits after the implied decimal point, including no implied decimal point, try unsigned as well as signed, and try different total number of digits.  Then run the program in Inspect and display each of the fields and see what value Inspect shows.  You might find that Inspect seems to display some kinds of comp-3 fields correctly.  If so, then you might be safe in using Inspect to display those kinds of comp-3 fields in the normal way and only resort to the hex display for the kinds of comp-3 fields that Inspect does incorrectly.  Even if Inspect displays some of the fields correctly, I cannot guarantee that you will be able to find a pattern in the results that will let you know when you can trust the Inspect display.

On Dec 16, 2:31=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
> ChinmaYT wrote:
> > On Dec 16, 7:34 am, spamb...@milmac.com (Doug Miller) wrote:
>
> >>In article <Z6idncX0HtUGaLrWnZ2dnUVZ_qOdn...@giganews.com>, kd...@acm.o=
rg wrote:
>
> >>>It seems a little odd that the Inspect display of FIELD-A shows a + si=
gn, but
> >>>the display of FIELD-B does not show a + sign. =A0Did you show us the =
correct
> >>>declaration for FIELD-B? =A0Is it signed or unsigned? =A0I do not reme=
mber whether
> >>>Inspect shows a sign for positive signed display numeric fields or not=
.. =A0Maybe
> >>>it does the display for COMP-3 differently than for ordinary display n=
umeric
> >>>fields.
>
> >>Keith, I don't believe for one minute that we're seeing a copy-and-past=
e
> >>either of actual code or of actual results. I think that if the OP woul=
d
> >>provide us with copies of his _actual_ program and his _actual_ Inspect
> >>session, the problem would become readily apparent.
>
> > I am using TNS E and H Searies Tandem System. Also the variable is in
> > a group and I am reading data from file.
> > I am unable to paste the whole structure here because of undisclose
> > policy.
>
> > -UNPAKDAT-info identifier FIELD-A
> > FIELD-A: VARIABLE
> > storage^info:
> > TYPE=3DPAK SIGN, ELEMENT LEN=3D4 BITS, UNIT SIZE=3D16 ELEMENTS, SCALE=
=3D5
> > access^info:
> > 'L' + 6S WORDS + %213 BYTES
> > structure^info:
> > PARENT=3DRECORD-A
>
> > -UNPAKDAT-info identifier FIELD-B
> > FIELD-B: VARIABLE
> > storage^info:
> > TYPE=3DNUM TR EM, ELEMENT LEN=3D8 BITS, UNIT SIZE=3D15 ELEMENTS, SCALE=
=3D5
> > access^info:
> > 'L' + %21S + %166 WORDS
> > structure^info:
> > PARENT=3DRECORD-B
>
> > -UNPAKDAT(STEP 1 V)-d FIELD-A
> > IN-FILE.RECORD-A.FIELD-A =3D =A0 =A0 =A0 =A0 =A0+0.00010
>
> > -UNPAKDAT-d FIELD-B
> > RECORD-B.FIELD-B =3D =A0 =A0 =A0 =A0100.00000
>
> > -UNPAKDAT-d FIELD-A whole in hex
> > IN-FILE.RECORD-A.FIELD-A =3D 0 0 0 1 0 0 0 %HC
>
> > -UNPAKDAT-d FIELD-B whole in hex
> > RECORD-B.FIELD-B =3D %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H30 %H30
> > %H30 %H30 %H30 %H30 %H30
>
> > The same case happens whatever I try ADD or MOVE or removing ROUNDED
> > from ADD statement.
>
> > I tried to modify the data of FIELD-A (m FIELD-A in debug)with the
> > same value +0.00010, and after (add/move whatever) it works fine and
> > correct value is moved.
>
> Inspect is displaying the value of the comp-3 field incorrectly. =A0If yo=
u look at the hex value for FIELD-A, remembering that each byte encodes two=
 digits and the picture has 5 digits following the implied decimal point, t=
he field contains 00000010000000+ which is 100. =A0So the value placed into=
 FIELD-B is correct.
>
> I am not sure what you mean when you said you modified FIELD-A in debug t=
o set it to +0.00010 and it worked correctly. =A0Did you display the value =
in FIELD-A after modifying it (display it both the regular way and in hex)?=
 =A0What does that show?
>
> So from what you have shown in this post, COBOL seems to be handling the =
data correctly. =A0The problem is that Inspect is displaying the value of t=
he comp-3 field incorrectly. =A0I believe you should construct a small exam=
ple program that demonstrates that Inspect displays that value incorrectly =
and use it to report the Inspect problem to GCSC, or whatever that group is=
 named now. =A0They should report the problem to Inspect development so the=
y can fix it.
>
> I cannot yet tell whether what you saw upon using Inspect to modify the v=
alue of FIELD-A is also an error. =A0My guess is that it does not show any =
further problem. =A0Maybe Inspect can store values into comp-3 fields corre=
ctly, but cannot display the values in comp-3 fields correctly.
>
> Until you get a corrected version of Inspect, you should not trust the va=
lues Inspect shows for comp-3 fields. =A0If you must learn the value of a c=
omp-3 field, use the method of displaying it in hex, then interpret the hex=
 digits to figure out what the value is. =A0
>
> If you want to take time to experiment to see whether Inspect handles som=
e comp-3 fields correctly, try storing 100 into comp-3 fields with differen=
t pictures. =A0Try different numbers of digits after the implied decimal po=
int, including no implied decimal point, try unsigned as well as signed, an=
d try different total number of digits. =A0Then run the program in Inspect =
and display each of the fields and see what value Inspect shows. =A0You mig=
ht find that Inspect seems to display some kinds of comp-3 fields correctly=
.. =A0If so, then you might be safe in using Inspect to display those kinds =
of comp-3 fields in the normal way and only resort to the hex display for t=
he kinds of comp-3 fields that Inspect does incorrectly. =A0Even if Inspect=
 displays some of the fields correctly, I cannot guarantee that you will be=
 able to find a pattern in the results that will let you know when you can =
trust the Inspect display.

Yes Keith, you are right. The version of inspect that i am using is
unable to display the packed data correctly

I tried following

WORKING-STORAGE:
       01 FIELD-A                         PIC S9(10)V9(5) COMP-3 VALUE
100.
       01 FIELD-B                         PIC S9(10)V9(5).
PROCEDURE DIVISION

           MOVE FIELD-A                     TO FIELD-B.

And during debugging:
-UNPAKDAT(STEP 1 V)-D FIELD-A
FIELD-A =3D          +0.00010

-UNPAKDAT-D FIELD-B
** Inspect warning 109 ** Non-numeric character in numeric string
FIELD-B =3D          0.00000

-UNPAKDAT-D FIELD-A IN HEX
FIELD-A =3D 0 0 0 1 0 0 0 %HC

-UNPAKDAT-D FIELD-B IN HEX
FIELD-B =3D %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20
%H20 %H20 %H20


Execute =3D MOVE FIELD-A                     TO FIELD-B.


-UNPAKDAT(STEP 1 V)-D FIELD-A
FIELD-A =3D          +0.00010

-UNPAKDAT-D FIELD-A IN HEX
FIELD-A =3D 0 0 0 1 0 0 0 %HC

-UNPAKDAT-D FIELD-B
FIELD-B =3D        100.00000

-UNPAKDAT-D FIELD-B IN HEX
FIELD-B =3D %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H30 %H30 %H30 %H30
%H30 %H30 %H30


Thanks for your help. :)

ChinmaYT wrote:
> On Dec 16, 2:31 pm, Keith Dick <KeithD...@earthlink.net> wrote:
> 
>>ChinmaYT wrote:
>>
>>>On Dec 16, 7:34 am, spamb...@milmac.com (Doug Miller) wrote:
>>
>>>>In article <Z6idncX0HtUGaLrWnZ2dnUVZ_qOdn...@giganews.com>, kd...@acm.org wrote:
>>
>>>>>It seems a little odd that the Inspect display of FIELD-A shows a + sign, but
>>>>>the display of FIELD-B does not show a + sign.  Did you show us the correct
>>>>>declaration for FIELD-B?  Is it signed or unsigned?  I do not remember whether
>>>>>Inspect shows a sign for positive signed display numeric fields or not.  Maybe
>>>>>it does the display for COMP-3 differently than for ordinary display numeric
>>>>>fields.
>>
>>>>Keith, I don't believe for one minute that we're seeing a copy-and-paste
>>>>either of actual code or of actual results. I think that if the OP would
>>>>provide us with copies of his _actual_ program and his _actual_ Inspect
>>>>session, the problem would become readily apparent.
>>
>>>I am using TNS E and H Searies Tandem System. Also the variable is in
>>>a group and I am reading data from file.
>>>I am unable to paste the whole structure here because of undisclose
>>>policy.
>>
>>>-UNPAKDAT-info identifier FIELD-A
>>>FIELD-A: VARIABLE
>>>storage^info:
>>>TYPE=PAK SIGN, ELEMENT LEN=4 BITS, UNIT SIZE=16 ELEMENTS, SCALE=5
>>>access^info:
>>>'L' + 6S WORDS + %213 BYTES
>>>structure^info:
>>>PARENT=RECORD-A
>>
>>>-UNPAKDAT-info identifier FIELD-B
>>>FIELD-B: VARIABLE
>>>storage^info:
>>>TYPE=NUM TR EM, ELEMENT LEN=8 BITS, UNIT SIZE=15 ELEMENTS, SCALE=5
>>>access^info:
>>>'L' + %21S + %166 WORDS
>>>structure^info:
>>>PARENT=RECORD-B
>>
>>>-UNPAKDAT(STEP 1 V)-d FIELD-A
>>>IN-FILE.RECORD-A.FIELD-A =          +0.00010
>>
>>>-UNPAKDAT-d FIELD-B
>>>RECORD-B.FIELD-B =        100.00000
>>
>>>-UNPAKDAT-d FIELD-A whole in hex
>>>IN-FILE.RECORD-A.FIELD-A = 0 0 0 1 0 0 0 %HC
>>
>>>-UNPAKDAT-d FIELD-B whole in hex
>>>RECORD-B.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H30 %H30
>>>%H30 %H30 %H30 %H30 %H30
>>
>>>The same case happens whatever I try ADD or MOVE or removing ROUNDED
>>>from ADD statement.
>>
>>>I tried to modify the data of FIELD-A (m FIELD-A in debug)with the
>>>same value +0.00010, and after (add/move whatever) it works fine and
>>>correct value is moved.
>>
>>Inspect is displaying the value of the comp-3 field incorrectly.  If you look at the hex value for FIELD-A, remembering that each byte encodes two digits and the picture has 5 digits following the implied decimal point, the field contains 00000010000000+ which is 100.  So the value placed into FIELD-B is correct.
>>
>>I am not sure what you mean when you said you modified FIELD-A in debug to set it to +0.00010 and it worked correctly.  Did you display the value in FIELD-A after modifying it (display it both the regular way and in hex)?  What does that show?
>>
>>So from what you have shown in this post, COBOL seems to be handling the data correctly.  The problem is that Inspect is displaying the value of the comp-3 field incorrectly.  I believe you should construct a small example program that demonstrates that Inspect displays that value incorrectly and use it to report the Inspect problem to GCSC, or whatever that group is named now.  They should report the problem to Inspect development so they can fix it.
>>
>>I cannot yet tell whether what you saw upon using Inspect to modify the value of FIELD-A is also an error.  My guess is that it does not show any further problem.  Maybe Inspect can store values into comp-3 fields correctly, but cannot display the values in comp-3 fields correctly.
>>
>>Until you get a corrected version of Inspect, you should not trust the values Inspect shows for comp-3 fields.  If you must learn the value of a comp-3 field, use the method of displaying it in hex, then interpret the hex digits to figure out what the value is.  
>>
>>If you want to take time to experiment to see whether Inspect handles some comp-3 fields correctly, try storing 100 into comp-3 fields with different pictures.  Try different numbers of digits after the implied decimal point, including no implied decimal point, try unsigned as well as signed, and try different total number of digits.  Then run the program in Inspect and display each of the fields and see what value Inspect shows.  You might find that Inspect seems to display some kinds of comp-3 fields correctly.  If so, then you might be safe in using Inspect to display those kinds of comp-3 fields in the normal way and only resort to the hex display for the kinds of comp-3 fields that Inspect does incorrectly.  Even if Inspect displays some of the fields correctly, I cannot guarantee that you will be able to find a pattern in the results that will let you know when you can trust the Inspect display.
> 
> 
> Yes Keith, you are right. The version of inspect that i am using is
> unable to display the packed data correctly
> 
> I tried following
> 
> WORKING-STORAGE:
>        01 FIELD-A                         PIC S9(10)V9(5) COMP-3 VALUE
> 100.
>        01 FIELD-B                         PIC S9(10)V9(5).
> PROCEDURE DIVISION
> 
>            MOVE FIELD-A                     TO FIELD-B.
> 
> And during debugging:
> -UNPAKDAT(STEP 1 V)-D FIELD-A
> FIELD-A =          +0.00010
> 
> -UNPAKDAT-D FIELD-B
> ** Inspect warning 109 ** Non-numeric character in numeric string
> FIELD-B =          0.00000
> 
> -UNPAKDAT-D FIELD-A IN HEX
> FIELD-A = 0 0 0 1 0 0 0 %HC
> 
> -UNPAKDAT-D FIELD-B IN HEX
> FIELD-B = %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20 %H20
> %H20 %H20 %H20
> 
> 
> Execute = MOVE FIELD-A                     TO FIELD-B.
> 
> 
> -UNPAKDAT(STEP 1 V)-D FIELD-A
> FIELD-A =          +0.00010
> 
> -UNPAKDAT-D FIELD-A IN HEX
> FIELD-A = 0 0 0 1 0 0 0 %HC
> 
> -UNPAKDAT-D FIELD-B
> FIELD-B =        100.00000
> 
> -UNPAKDAT-D FIELD-B IN HEX
> FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H30 %H30 %H30 %H30
> %H30 %H30 %H30
> 
> 
> Thanks for your help. :)
> 

You are welcome.  I am glad I was able to help.

Please report the problem to HP Customer Support that Inspect displays the value in your comp-3 field incorrectly.  If you do not have a way to report it yourself, there must be someone in your company who deals with reporting problems to HP Customer Support.  Reporting the problem will help make sure it gets fixed.

In article <f9514ebe-9749-45d1-baeb-26c93e922ba4@n31g2000vbt.googlegroups.com>, ChinmaYT <chinmay13@gmail.com> wrote:

>-UNPAKDAT-info identifier FIELD-A
>FIELD-A: VARIABLE
>storage^info:
>TYPE=PAK SIGN, ELEMENT LEN=4 BITS, UNIT SIZE=16 ELEMENTS, SCALE=5
>access^info:
>'L' + 6S WORDS + %213 BYTES
>structure^info:
>PARENT=RECORD-A
[...]
>-UNPAKDAT(STEP 1 V)-d FIELD-A
>IN-FILE.RECORD-A.FIELD-A =          +0.00010
[...]
>-UNPAKDAT-d FIELD-A whole in hex
>IN-FILE.RECORD-A.FIELD-A = 0 0 0 1 0 0 0 %HC

Submit a bug report on Inspect. It's not displaying the value of FIELD-A 
correctly. 

It would be even more instructive if you display FIELD-A in binary instead of 
hex. This is what you'd see:

00000000 00000000 00000000 00000001 00000000 00000000 00000000 00001100

Remember that each byte of a packed decimal field contains *two* decimal 
digits -- so the decimal digits contained in this field are

0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 C (where the last one, C, is the + sign).

Given the item's description PIC 9(3)V9(5) COMP, this means a value of 
100.00000 -- exactly what is moved to FIELD-B.

>-UNPAKDAT-d FIELD-B whole in hex
>RECORD-B.FIELD-B  %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H30 %H30
>%H30 %H30 %H30 %H30 %H30

Yep -- %H30 = ASCII 0, %H31 = ASCII 1, so this field contains
0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
just as it should.
>
>The same case happens whatever I try ADD or MOVE or removing ROUNDED
>from ADD statement.

That's unsurprising, since the program is behaving correctly. It's INSPECT 
that's not working properly.
>
>I tried to modify the data of FIELD-A (m FIELD-A in debug)with the
>same value +0.00010, and after (add/move whatever) it works fine and
>correct value is moved.

???

The correct value is being moved *already* -- as you would see if you had 
followed through with Keith's suggestion to put COBOL DISPLAY statements in 
the program before and after the MOVE.

In article <85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>, 
chinmay13@gmail.com says...
>
>Hello,
>
>I have a field
>     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>I am trying to convert it to unpacked field
>     04 FIELD-B                 PIC S9(10)V9(5).
>
>I am doing
>        ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>
>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>How to get correct value in FIELD-B?




Seems TNS mode has some sort of issue with that


  204.1                  move 123.456 to field-a.
  204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.


TNS mode 

-TESTCOB(STEP)-d field-a
PACKED-STUFF.FIELD-A =        +123.45600
-TESTCOB-d field-b
PACKED-STUFF.FIELD-B =       1234.56000

Native mode 

(eInspect 0,574):p field-a
$1 = 0000000123.45600
(eInspect 0,574):p field-b
$2 = 0000000123.45600

In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com (JShepherd) wrote:
>In article <85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
> 
>chinmay13@gmail.com says...
>>
>>Hello,
>>
>>I have a field
>>     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>I am trying to convert it to unpacked field
>>     04 FIELD-B                 PIC S9(10)V9(5).
>>
>>I am doing
>>        ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>
>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>How to get correct value in FIELD-B?
>
>
>
>
>Seems TNS mode has some sort of issue with that
>
>
>  204.1                  move 123.456 to field-a.
>  204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>
>
>TNS mode 
>
>-TESTCOB(STEP)-d field-a
>PACKED-STUFF.FIELD-A =        +123.45600
>-TESTCOB-d field-b
>PACKED-STUFF.FIELD-B =       1234.56000
>
>Native mode 
>
>(eInspect 0,574):p field-a
>$1 = 0000000123.45600
>(eInspect 0,574):p field-b
>$2 = 0000000123.45600
>

What's the result of a COBOL DISPLAY statement on each field? Are the fields 
actually corrupt, or is Inspect just displaying them incorrectly?

JShepherd wrote:
> In article <85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>, 
> chinmay13@gmail.com says...
> 
>>Hello,
>>
>>I have a field
>>    04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>I am trying to convert it to unpacked field
>>    04 FIELD-B                 PIC S9(10)V9(5).
>>
>>I am doing
>>       ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>
>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>How to get correct value in FIELD-B?
> 
> 
> 
> 
> 
> Seems TNS mode has some sort of issue with that
> 
> 
>   204.1                  move 123.456 to field-a.
>   204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
> 
> 
> TNS mode 
> 
> -TESTCOB(STEP)-d field-a
> PACKED-STUFF.FIELD-A =        +123.45600
> -TESTCOB-d field-b
> PACKED-STUFF.FIELD-B =       1234.56000
>
This is a little surprising.  If your FIELD-A is comp-3 and your FIELD-B is not comp-3, then you are seeing the opposite of what the original poster saw.  He saw that Inspect displays the value of a comp-3 field wrong.  His later posts showed the actual contents of the fields using DISPLAY x WHOLE IN HEX, which showed that COBOL was doing nothing wrong.  It was Inspect that was wrong, putting the decimal point in the wrong place.  It would be interesting to see your data declarations and Inspect's hex display of the two fields.
 

In article <hgbkvp$emm$2@news.eternal-september.org>, spambait@milmac.com 
says...
>
>In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com 
(JShep
>herd) wrote:
>>In article 
<85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>> 
>>chinmay13@gmail.com says...
>>>
>>>Hello,
>>>
>>>I have a field
>>>     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>I am trying to convert it to unpacked field
>>>     04 FIELD-B                 PIC S9(10)V9(5).
>>>
>>>I am doing
>>>        ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>
>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>How to get correct value in FIELD-B?
>>
>>
>>
>>
>>Seems TNS mode has some sort of issue with that
>>
>>
>>  204.1                  move 123.456 to field-a.
>>  204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>
>>
>>TNS mode 
>>
>>-TESTCOB(STEP)-d field-a
>>PACKED-STUFF.FIELD-A =        +123.45600
>>-TESTCOB-d field-b
>>PACKED-STUFF.FIELD-B =       1234.56000
>>
>>Native mode 
>>
>>(eInspect 0,574):p field-a
>>$1 = 0000000123.45600
>>(eInspect 0,574):p field-b
>>$2 = 0000000123.45600
>>
>
>What's the result of a COBOL DISPLAY statement on each field? Are the fields 
>actually corrupt, or is Inspect just displaying them incorrectly?



Same as inspect
Adding the comp-3 to comp works correctly.

JShepherd wrote:
> In article <hgbkvp$emm$2@news.eternal-september.org>, spambait@milmac.com 
> says...
> 
>>In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com 
> 
> (JShep
> 
>>herd) wrote:
>>
>>>In article 
> 
> <85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
> 
>>>chinmay13@gmail.com says...
>>>
>>>>Hello,
>>>>
>>>>I have a field
>>>>    04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>I am trying to convert it to unpacked field
>>>>    04 FIELD-B                 PIC S9(10)V9(5).
>>>>
>>>>I am doing
>>>>       ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>
>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>How to get correct value in FIELD-B?
>>>
>>>
>>>
>>>
>>>Seems TNS mode has some sort of issue with that
>>>
>>>
>>> 204.1                  move 123.456 to field-a.
>>> 204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>
>>>
>>>TNS mode 
>>>
>>>-TESTCOB(STEP)-d field-a
>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>-TESTCOB-d field-b
>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>
>>>Native mode 
>>>
>>>(eInspect 0,574):p field-a
>>>$1 = 0000000123.45600
>>>(eInspect 0,574):p field-b
>>>$2 = 0000000123.45600
>>>
>>
>>What's the result of a COBOL DISPLAY statement on each field? Are the fields 
>>actually corrupt, or is Inspect just displaying them incorrectly?
> 
> 
> 
> 
> Same as inspect
> Adding the comp-3 to comp works correctly.
> 

I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same as Inspect does, how can it be that "adding the comp-3 to comp works correctly" be a true statement?  If things are working correctly, the two values should be the same, but the Inspect display shows one is 10 times the value of the other.

Come to think of it, the original poster's case had no comp fields.  He had one comp-3 and one display numeric.  Are you using a comp field somewhere in there?

As they told us in high school, you haven't shown enough of your work to get full credit. (joke)

If you could, please show the declaration of FIELD-A and FIELD-B, put COBOL DISPLAY statements for both FIELD-A and FIELD-B in the program after the ADD statement, show the results of the COBOL DISPLAYs, and show the results of these Inspect commands:

   D FIELD-A
   D FIELD-A WHOLE IN HEX
   D FIELD-B
   D FIELD-B WHOLE IN HEX

I think that would be enough to show whether COBOL is doing arithmetic with comp-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, and whether Inspect is displaying comp-3 fields correctly.

I think the follow-ups from the original guy showed that, in his example, COBOL was doing the arithmetic and/or move with the comp-3 field correctly.  Inspect was displaying his comp-3 field incorrectly.  I believe he did not show us any COBOL DISPLAYs.

In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdnZ2d@giganews.com>, 
KeithDick@earthlink.net says...
>
>JShepherd wrote:
>> In article <hgbkvp$emm$2@news.eternal-september.org>, spambait@milmac.com 
>> says...
>> 
>>>In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com 
>> 
>> (JShep
>> 
>>>herd) wrote:
>>>
>>>>In article 
>> 
>> <85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>> 
>>>>chinmay13@gmail.com says...
>>>>
>>>>>Hello,
>>>>>
>>>>>I have a field
>>>>>    04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>I am trying to convert it to unpacked field
>>>>>    04 FIELD-B                 PIC S9(10)V9(5).
>>>>>
>>>>>I am doing
>>>>>       ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>>
>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>>How to get correct value in FIELD-B?
>>>>
>>>>
>>>>
>>>>
>>>>Seems TNS mode has some sort of issue with that
>>>>
>>>>
>>>> 204.1                  move 123.456 to field-a.
>>>> 204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>
>>>>
>>>>TNS mode 
>>>>
>>>>-TESTCOB(STEP)-d field-a
>>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>>-TESTCOB-d field-b
>>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>>
>>>>Native mode 
>>>>
>>>>(eInspect 0,574):p field-a
>>>>$1 = 0000000123.45600
>>>>(eInspect 0,574):p field-b
>>>>$2 = 0000000123.45600
>>>>
>>>
>>>What's the result of a COBOL DISPLAY statement on each field? Are the fields 
>>>actually corrupt, or is Inspect just displaying them incorrectly?
>> 
>> 
>> 
>> 
>> Same as inspect
>> Adding the comp-3 to comp works correctly.
>> 
>
>I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same as 
Insp
>ect does, how can it be that "adding the comp-3 to comp works correctly" be a 
tr
>ue statement?  If things are working correctly, the two values should be the 
sam
>e, but the Inspect display shows one is 10 times the value of the other.
>
>Come to think of it, the original poster's case had no comp fields.  He had 
one 
>comp-3 and one display numeric.  Are you using a comp field somewhere in 
there?
>
>As they told us in high school, you haven't shown enough of your work to get 
ful
>l credit. (joke)
>
>If you could, please show the declaration of FIELD-A and FIELD-B, put COBOL 
DISP
>LAY statements for both FIELD-A and FIELD-B in the program after the ADD 
stateme
>nt, show the results of the COBOL DISPLAYs, and show the results of these 
Inspec
>t commands:
>
>   D FIELD-A
>   D FIELD-A WHOLE IN HEX
>   D FIELD-B
>   D FIELD-B WHOLE IN HEX
>
>I think that would be enough to show whether COBOL is doing arithmetic with 
comp
>-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, and 
wh
>ether Inspect is displaying comp-3 fields correctly.
>
>I think the follow-ups from the original guy showed that, in his example, 
COBOL 
>was doing the arithmetic and/or move with the comp-3 field correctly.  Inspect 
w
>as displaying his comp-3 field incorrectly.  I believe he did not show us any 
CO
>BOL DISPLAYs.


The issue seems to be in TNS mode
from a COMP-3 field to a usage display field.

 01 packed-stuff.
    04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
    04 FIELD-B                 PIC S9(10)V9(5).
    04 FIELD-C                 PIC S9(10)V9(5) comp.
    04 FIELD-D                 PIC S9(10)V9(5) usage display.

 0000-BEGIN.
    move 123.456 to field-a.
    ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
    ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
    ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
    display field-a "   // COMP-3".
    display field-b "   // no usage option".
    display field-c "   // COMP         ".
    display field-d "   // Usage display".
    stop run.


TNS mode 
0000000123.45600   // COMP-3
0000001234.56000   // no usage option
0000000123.45600   // COMP
0000001234.56000   // Usage display

Native mode 
0000000123.45600   // COMP-3
0000000123.45600   // no usage option
0000000123.45600   // COMP
0000000123.45600   // Usage display

JShepherd wrote:
> In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdnZ2d@giganews.com>, 
> KeithDick@earthlink.net says...
> 
>>JShepherd wrote:
>>
>>>In article <hgbkvp$emm$2@news.eternal-september.org>, spambait@milmac.com 
>>>says...
>>>
>>>
>>>>In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com 
>>>
>>>(JShep
>>>
>>>
>>>>herd) wrote:
>>>>
>>>>
>>>>>In article 
>>>
>>><85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>>>
>>>
>>>>>chinmay13@gmail.com says...
>>>>>
>>>>>
>>>>>>Hello,
>>>>>>
>>>>>>I have a field
>>>>>>   04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>>I am trying to convert it to unpacked field
>>>>>>   04 FIELD-B                 PIC S9(10)V9(5).
>>>>>>
>>>>>>I am doing
>>>>>>      ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>
>>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>>>How to get correct value in FIELD-B?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Seems TNS mode has some sort of issue with that
>>>>>
>>>>>
>>>>>204.1                  move 123.456 to field-a.
>>>>>204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>
>>>>>
>>>>>TNS mode 
>>>>>
>>>>>-TESTCOB(STEP)-d field-a
>>>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>>>-TESTCOB-d field-b
>>>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>>>
>>>>>Native mode 
>>>>>
>>>>>(eInspect 0,574):p field-a
>>>>>$1 = 0000000123.45600
>>>>>(eInspect 0,574):p field-b
>>>>>$2 = 0000000123.45600
>>>>>
>>>>
>>>>What's the result of a COBOL DISPLAY statement on each field? Are the fields 
>>>>actually corrupt, or is Inspect just displaying them incorrectly?
>>>
>>>
>>>
>>>
>>>Same as inspect
>>>Adding the comp-3 to comp works correctly.
>>>
>>
>>I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same as 
> 
> Insp
> 
>>ect does, how can it be that "adding the comp-3 to comp works correctly" be a 
> 
> tr
> 
>>ue statement?  If things are working correctly, the two values should be the 
> 
> sam
> 
>>e, but the Inspect display shows one is 10 times the value of the other.
>>
>>Come to think of it, the original poster's case had no comp fields.  He had 
> 
> one 
> 
>>comp-3 and one display numeric.  Are you using a comp field somewhere in 
> 
> there?
> 
>>As they told us in high school, you haven't shown enough of your work to get 
> 
> ful
> 
>>l credit. (joke)
>>
>>If you could, please show the declaration of FIELD-A and FIELD-B, put COBOL 
> 
> DISP
> 
>>LAY statements for both FIELD-A and FIELD-B in the program after the ADD 
> 
> stateme
> 
>>nt, show the results of the COBOL DISPLAYs, and show the results of these 
> 
> Inspec
> 
>>t commands:
>>
>>  D FIELD-A
>>  D FIELD-A WHOLE IN HEX
>>  D FIELD-B
>>  D FIELD-B WHOLE IN HEX
>>
>>I think that would be enough to show whether COBOL is doing arithmetic with 
> 
> comp
> 
>>-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, and 
> 
> wh
> 
>>ether Inspect is displaying comp-3 fields correctly.
>>
>>I think the follow-ups from the original guy showed that, in his example, 
> 
> COBOL 
> 
>>was doing the arithmetic and/or move with the comp-3 field correctly.  Inspect 
> 
> w
> 
>>as displaying his comp-3 field incorrectly.  I believe he did not show us any 
> 
> CO
> 
>>BOL DISPLAYs.
> 
> 
> 
> The issue seems to be in TNS mode
> from a COMP-3 field to a usage display field.
> 
>  01 packed-stuff.
>     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>     04 FIELD-B                 PIC S9(10)V9(5).
>     04 FIELD-C                 PIC S9(10)V9(5) comp.
>     04 FIELD-D                 PIC S9(10)V9(5) usage display.
> 
>  0000-BEGIN.
>     move 123.456 to field-a.
>     ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>     ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
>     ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
>     display field-a "   // COMP-3".
>     display field-b "   // no usage option".
>     display field-c "   // COMP         ".
>     display field-d "   // Usage display".
>     stop run.
> 
> 
> TNS mode 
> 0000000123.45600   // COMP-3
> 0000001234.56000   // no usage option
> 0000000123.45600   // COMP
> 0000001234.56000   // Usage display
> 
> Native mode 
> 0000000123.45600   // COMP-3
> 0000000123.45600   // no usage option
> 0000000123.45600   // COMP
> 0000000123.45600   // Usage display
> 
> 
> 
Ah, now I understand what you are seeing.  Thanks for the additional information.  But we need still a little more to be sure exactly where the problem is.  From the evidence in your post, it seems likely that the problem is that the ADD puts the wrong result into the display numeric field, but I would like to see Inspect's hex display of the value of all of the fields, just to be sure.

In the original case from ChinmaYT, the Inspect hex displays showed that the actual values in the variables were correct, so COBOL was working correctly and the only problem he had was that Inspect was displaying the value of the comp-3 field incorrectly when asked to display it normally (not in hex).  You seem to have found a different problem if the results of COBOL's DISPLAY can be believed, and it would be very surprising if DISPLAY of a display numeric field wasn't working correctly.

It seems rather odd that in the original case the COBOL statements worked correctly but your case seems to show that COBOL is computing a wrong result.  I wonder whether I misunderstood the evidence from the original case.  I will go look at those posts again.

If you are willing to do a little more experimenting, I'd like to see the following for the TNS mode program:

Inspect output from D FIELD-x WHOLE IN HEX for all the fields.

Change the program to replace the ADD statements with simple MOVE statements from FIELD-A to the other fields and show both the COBOL DISPLAY output and the Inspect display of the hex values for all of the fields.

You could drop FIELD-D, since USAGE DISPLAY is the default, but if you want to leave it in, that's fine.

I expect that the optimization level does not affect this, but it would be best to check to see whether specifying OPTIMIZE 0 fixes it.

In article <YP2dnSxUUoR2_bfWnZ2dnUVZ_hednZ2d@giganews.com>, 
KeithDick@earthlink.net says...
>
>JShepherd wrote:
>> In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdnZ2d@giganews.com>, 
>> KeithDick@earthlink.net says...
>> 
>>>JShepherd wrote:
>>>
>>>>In article <hgbkvp$emm$2@news.eternal-september.org>, spambait@milmac.com 
>>>>says...
>>>>
>>>>
>>>>>In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com 
>>>>
>>>>(JShep
>>>>
>>>>
>>>>>herd) wrote:
>>>>>
>>>>>
>>>>>>In article 
>>>>
>>>><85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>>>>
>>>>
>>>>>>chinmay13@gmail.com says...
>>>>>>
>>>>>>
>>>>>>>Hello,
>>>>>>>
>>>>>>>I have a field
>>>>>>>   04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>>>I am trying to convert it to unpacked field
>>>>>>>   04 FIELD-B                 PIC S9(10)V9(5).
>>>>>>>
>>>>>>>I am doing
>>>>>>>      ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>
>>>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>>>>How to get correct value in FIELD-B?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Seems TNS mode has some sort of issue with that
>>>>>>
>>>>>>
>>>>>>204.1                  move 123.456 to field-a.
>>>>>>204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>
>>>>>>
>>>>>>TNS mode 
>>>>>>
>>>>>>-TESTCOB(STEP)-d field-a
>>>>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>>>>-TESTCOB-d field-b
>>>>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>>>>
>>>>>>Native mode 
>>>>>>
>>>>>>(eInspect 0,574):p field-a
>>>>>>$1 = 0000000123.45600
>>>>>>(eInspect 0,574):p field-b
>>>>>>$2 = 0000000123.45600
>>>>>>
>>>>>
>>>>>What's the result of a COBOL DISPLAY statement on each field? Are the 
fields
> 
>>>>>actually corrupt, or is Inspect just displaying them incorrectly?
>>>>
>>>>
>>>>
>>>>
>>>>Same as inspect
>>>>Adding the comp-3 to comp works correctly.
>>>>
>>>
>>>I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same as 
>> 
>> Insp
>> 
>>>ect does, how can it be that "adding the comp-3 to comp works correctly" be 
a 
>> 
>> tr
>> 
>>>ue statement?  If things are working correctly, the two values should be the 
>> 
>> sam
>> 
>>>e, but the Inspect display shows one is 10 times the value of the other.
>>>
>>>Come to think of it, the original poster's case had no comp fields.  He had 
>> 
>> one 
>> 
>>>comp-3 and one display numeric.  Are you using a comp field somewhere in 
>> 
>> there?
>> 
>>>As they told us in high school, you haven't shown enough of your work to get 
>> 
>> ful
>> 
>>>l credit. (joke)
>>>
>>>If you could, please show the declaration of FIELD-A and FIELD-B, put COBOL 
>> 
>> DISP
>> 
>>>LAY statements for both FIELD-A and FIELD-B in the program after the ADD 
>> 
>> stateme
>> 
>>>nt, show the results of the COBOL DISPLAYs, and show the results of these 
>> 
>> Inspec
>> 
>>>t commands:
>>>
>>>  D FIELD-A
>>>  D FIELD-A WHOLE IN HEX
>>>  D FIELD-B
>>>  D FIELD-B WHOLE IN HEX
>>>
>>>I think that would be enough to show whether COBOL is doing arithmetic with 
>> 
>> comp
>> 
>>>-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, 
and 
>> 
>> wh
>> 
>>>ether Inspect is displaying comp-3 fields correctly.
>>>
>>>I think the follow-ups from the original guy showed that, in his example, 
>> 
>> COBOL 
>> 
>>>was doing the arithmetic and/or move with the comp-3 field correctly.  
Inspect
> 
>> 
>> w
>> 
>>>as displaying his comp-3 field incorrectly.  I believe he did not show us 
any 
>> 
>> CO
>> 
>>>BOL DISPLAYs.
>> 
>> 
>> 
>> The issue seems to be in TNS mode
>> from a COMP-3 field to a usage display field.
>> 
>>  01 packed-stuff.
>>     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>     04 FIELD-B                 PIC S9(10)V9(5).
>>     04 FIELD-C                 PIC S9(10)V9(5) comp.
>>     04 FIELD-D                 PIC S9(10)V9(5) usage display.
>> 
>>  0000-BEGIN.
>>     move 123.456 to field-a.
>>     ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>     ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
>>     ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
>>     display field-a "   // COMP-3".
>>     display field-b "   // no usage option".
>>     display field-c "   // COMP         ".
>>     display field-d "   // Usage display".
>>     stop run.
>> 
>> 
>> TNS mode 
>> 0000000123.45600   // COMP-3
>> 0000001234.56000   // no usage option
>> 0000000123.45600   // COMP
>> 0000001234.56000   // Usage display
>> 
>> Native mode 
>> 0000000123.45600   // COMP-3
>> 0000000123.45600   // no usage option
>> 0000000123.45600   // COMP
>> 0000000123.45600   // Usage display
>> 
>> 
>> 
>Ah, now I understand what you are seeing.  Thanks for the additional 
information
>.  But we need still a little more to be sure exactly where the problem is.  
Fro
>m the evidence in your post, it seems likely that the problem is that the ADD 
pu
>ts the wrong result into the display numeric field, but I would like to see 
Insp
>ect's hex display of the value of all of the fields, just to be sure.
>
>In the original case from ChinmaYT, the Inspect hex displays showed that the 
act
>ual values in the variables were correct, so COBOL was working correctly and 
the
> only problem he had was that Inspect was displaying the value of the comp-3 
fie
>ld incorrectly when asked to display it normally (not in hex).  You seem to 
have
> found a different problem if the results of COBOL's DISPLAY can be believed, 
an
>d it would be very surprising if DISPLAY of a display numeric field wasn't 
worki
>ng correctly.
>
>It seems rather odd that in the original case the COBOL statements worked 
correc
>tly but your case seems to show that COBOL is computing a wrong result.  I 
wonde
>r whether I misunderstood the evidence from the original case.  I will go look 
a
>t those posts again.
>
>If you are willing to do a little more experimenting, I'd like to see the 
follow
>ing for the TNS mode program:
>
>Inspect output from D FIELD-x WHOLE IN HEX for all the fields.
>
>Change the program to replace the ADD statements with simple MOVE statements 
fro
>m FIELD-A to the other fields and show both the COBOL DISPLAY output and the 
Ins
>pect display of the hex values for all of the fields.
>
>You could drop FIELD-D, since USAGE DISPLAY is the default, but if you want to 
l
>eave it in, that's fine.
>
>I expect that the optimization level does not affect this, but it would be 
best 
>to check to see whether specifying OPTIMIZE 0 fixes it.



TNS mode Optimization level does not change the result
Accelerating the TNS mode object does not change the result

---------------------

AFTER ADD Zero 

-TESTCOB(STEP)-d field-a in hex
PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC

-TESTCOB-d field-b in hex
PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 %H35 
%H36 %H30 %H30 %H30
-TESTCOB-d field-b in a
PACKED-STUFF.FIELD-B = "000000123456000"

-TESTCOB-d field-c in hex
PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100

-----------------------
After Move 

-TESTCOB(STEP)-d field-a in hex
PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
-TESTCOB-d field-b in hex
PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 
%H35 %H36 %H30 %H30
-TESTCOB-d field-b in a
PACKED-STUFF.FIELD-B = "000000012345600"
-TESTCOB-d field-c in hex
PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100


----------------

TNS mode ADD zero
0000000123.45600   // COMP-3
0000001234.56000   // no usage option
0000000123.45600   // COMP

TNS mode move 
0000000123.45600   // COMP-3
0000000123.45600   // Move to no usage option
0000000123.45600   // move to comp

In article <hgdpih$sr$1@news.eternal-september.org>, invalid@nowhere.com 
says...
>
>In article <YP2dnSxUUoR2_bfWnZ2dnUVZ_hednZ2d@giganews.com>, 
>KeithDick@earthlink.net says...
>>
>>JShepherd wrote:
>>> In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdnZ2d@giganews.com>, 
>>> KeithDick@earthlink.net says...
>>> 
>>>>JShepherd wrote:
>>>>
>>>>>In article <hgbkvp$emm$2@news.eternal-september.org>, spambait@milmac.com 
>>>>>says...
>>>>>
>>>>>
>>>>>>In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com 
>>>>>
>>>>>(JShep
>>>>>
>>>>>
>>>>>>herd) wrote:
>>>>>>
>>>>>>
>>>>>>>In article 
>>>>>
>>>>><85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>>>>>
>>>>>
>>>>>>>chinmay13@gmail.com says...
>>>>>>>
>>>>>>>
>>>>>>>>Hello,
>>>>>>>>
>>>>>>>>I have a field
>>>>>>>>   04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>>>>I am trying to convert it to unpacked field
>>>>>>>>   04 FIELD-B                 PIC S9(10)V9(5).
>>>>>>>>
>>>>>>>>I am doing
>>>>>>>>      ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>>
>>>>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>>>>>How to get correct value in FIELD-B?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Seems TNS mode has some sort of issue with that
>>>>>>>
>>>>>>>
>>>>>>>204.1                  move 123.456 to field-a.
>>>>>>>204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>
>>>>>>>
>>>>>>>TNS mode 
>>>>>>>
>>>>>>>-TESTCOB(STEP)-d field-a
>>>>>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>>>>>-TESTCOB-d field-b
>>>>>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>>>>>
>>>>>>>Native mode 
>>>>>>>
>>>>>>>(eInspect 0,574):p field-a
>>>>>>>$1 = 0000000123.45600
>>>>>>>(eInspect 0,574):p field-b
>>>>>>>$2 = 0000000123.45600
>>>>>>>
>>>>>>
>>>>>>What's the result of a COBOL DISPLAY statement on each field? Are the 
>fields
>> 
>>>>>>actually corrupt, or is Inspect just displaying them incorrectly?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Same as inspect
>>>>>Adding the comp-3 to comp works correctly.
>>>>>
>>>>
>>>>I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same as 
>>> 
>>> Insp
>>> 
>>>>ect does, how can it be that "adding the comp-3 to comp works correctly" be 
>a 
>>> 
>>> tr
>>> 
>>>>ue statement?  If things are working correctly, the two values should be 
the 
>>> 
>>> sam
>>> 
>>>>e, but the Inspect display shows one is 10 times the value of the other.
>>>>
>>>>Come to think of it, the original poster's case had no comp fields.  He had 
>>> 
>>> one 
>>> 
>>>>comp-3 and one display numeric.  Are you using a comp field somewhere in 
>>> 
>>> there?
>>> 
>>>>As they told us in high school, you haven't shown enough of your work to 
get 
>>> 
>>> ful
>>> 
>>>>l credit. (joke)
>>>>
>>>>If you could, please show the declaration of FIELD-A and FIELD-B, put COBOL 
>>> 
>>> DISP
>>> 
>>>>LAY statements for both FIELD-A and FIELD-B in the program after the ADD 
>>> 
>>> stateme
>>> 
>>>>nt, show the results of the COBOL DISPLAYs, and show the results of these 
>>> 
>>> Inspec
>>> 
>>>>t commands:
>>>>
>>>>  D FIELD-A
>>>>  D FIELD-A WHOLE IN HEX
>>>>  D FIELD-B
>>>>  D FIELD-B WHOLE IN HEX
>>>>
>>>>I think that would be enough to show whether COBOL is doing arithmetic with 
>>> 
>>> comp
>>> 
>>>>-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, 
>and 
>>> 
>>> wh
>>> 
>>>>ether Inspect is displaying comp-3 fields correctly.
>>>>
>>>>I think the follow-ups from the original guy showed that, in his example, 
>>> 
>>> COBOL 
>>> 
>>>>was doing the arithmetic and/or move with the comp-3 field correctly.  
>Inspect
>> 
>>> 
>>> w
>>> 
>>>>as displaying his comp-3 field incorrectly.  I believe he did not show us 
>any 
>>> 
>>> CO
>>> 
>>>>BOL DISPLAYs.
>>> 
>>> 
>>> 
>>> The issue seems to be in TNS mode
>>> from a COMP-3 field to a usage display field.
>>> 
>>>  01 packed-stuff.
>>>     04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>     04 FIELD-B                 PIC S9(10)V9(5).
>>>     04 FIELD-C                 PIC S9(10)V9(5) comp.
>>>     04 FIELD-D                 PIC S9(10)V9(5) usage display.
>>> 
>>>  0000-BEGIN.
>>>     move 123.456 to field-a.
>>>     ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>     ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
>>>     ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
>>>     display field-a "   // COMP-3".
>>>     display field-b "   // no usage option".
>>>     display field-c "   // COMP         ".
>>>     display field-d "   // Usage display".
>>>     stop run.
>>> 
>>> 
>>> TNS mode 
>>> 0000000123.45600   // COMP-3
>>> 0000001234.56000   // no usage option
>>> 0000000123.45600   // COMP
>>> 0000001234.56000   // Usage display
>>> 
>>> Native mode 
>>> 0000000123.45600   // COMP-3
>>> 0000000123.45600   // no usage option
>>> 0000000123.45600   // COMP
>>> 0000000123.45600   // Usage display
>>> 
>>> 
>>> 
>>Ah, now I understand what you are seeing.  Thanks for the additional 
>information
>>.  But we need still a little more to be sure exactly where the problem is.  
>Fro
>>m the evidence in your post, it seems likely that the problem is that the ADD 
>pu
>>ts the wrong result into the display numeric field, but I would like to see 
>Insp
>>ect's hex display of the value of all of the fields, just to be sure.
>>
>>In the original case from ChinmaYT, the Inspect hex displays showed that the 
>act
>>ual values in the variables were correct, so COBOL was working correctly and 
>the
>> only problem he had was that Inspect was displaying the value of the comp-3 
>fie
>>ld incorrectly when asked to display it normally (not in hex).  You seem to 
>have
>> found a different problem if the results of COBOL's DISPLAY can be believed, 
>an
>>d it would be very surprising if DISPLAY of a display numeric field wasn't 
>worki
>>ng correctly.
>>
>>It seems rather odd that in the original case the COBOL statements worked 
>correc
>>tly but your case seems to show that COBOL is computing a wrong result.  I 
>wonde
>>r whether I misunderstood the evidence from the original case.  I will go 
look 
>a
>>t those posts again.
>>
>>If you are willing to do a little more experimenting, I'd like to see the 
>follow
>>ing for the TNS mode program:
>>
>>Inspect output from D FIELD-x WHOLE IN HEX for all the fields.
>>
>>Change the program to replace the ADD statements with simple MOVE statements 
>fro
>>m FIELD-A to the other fields and show both the COBOL DISPLAY output and the 
>Ins
>>pect display of the hex values for all of the fields.
>>
>>You could drop FIELD-D, since USAGE DISPLAY is the default, but if you want 
to 
>l
>>eave it in, that's fine.
>>
>>I expect that the optimization level does not affect this, but it would be 
>best 
>>to check to see whether specifying OPTIMIZE 0 fixes it.
>
>
>
>TNS mode Optimization level does not change the result
>Accelerating the TNS mode object does not change the result
>
>---------------------
>
>AFTER ADD Zero 
>
>-TESTCOB(STEP)-d field-a in hex
>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>
>-TESTCOB-d field-b in hex
>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 %H35 
>%H36 %H30 %H30 %H30
>-TESTCOB-d field-b in a
>PACKED-STUFF.FIELD-B = "000000123456000"
>
>-TESTCOB-d field-c in hex
>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>
>-----------------------
>After Move 
>
>-TESTCOB(STEP)-d field-a in hex
>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>-TESTCOB-d field-b in hex
>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 
>%H35 %H36 %H30 %H30
>-TESTCOB-d field-b in a
>PACKED-STUFF.FIELD-B = "000000012345600"
>-TESTCOB-d field-c in hex
>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>
>
>----------------
>
>TNS mode ADD zero
>0000000123.45600   // COMP-3
>0000001234.56000   // no usage option
>0000000123.45600   // COMP
>
>TNS mode move 
>0000000123.45600   // COMP-3
>0000000123.45600   // Move to no usage option
>0000000123.45600   // move to comp
>


COMPUTE works where ADD fails.
MULTIPLY by 1 works.

    move 123.456 to field-a.
    display field-a "   // comp-3 value   ".
    ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
    display field-b "   // add zero       ".

    ADD FIELD-A TO 0.0000  GIVING FIELD-B ROUNDED.
    display field-b "   // add 0.0000     ".
 
    ADD FIELD-A TO 1  GIVING FIELD-B ROUNDED.
    display field-b "   // add 1          ".
 
    multiply FIELD-A by 1  GIVING FIELD-B ROUNDED.
    display field-b "   // multiply by 1      ".
 
    compute field-b = field-a + 0
    display field-b "   // compute field-b = field-a + 0 ".
 
    compute field-b = field-a + 1
    display field-b "   // compute field-b = field-a + 1 ".
    stop run.

0000000123.45600   // comp-3 value
0000001234.56000   // add zero
0000001234.56000   // add 0.0000
0000001244.56000   // add 1
0000000123.45600   // multiply by 1
0000000123.45600   // compute field-b = field-a + 0
0000000124.45600   // compute field-b = field-a + 1

JShepherd wrote:
> In article <hgdpih$sr$1@news.eternal-september.org>, invalid@nowhere.com 
> says...
> 
>>In article <YP2dnSxUUoR2_bfWnZ2dnUVZ_hednZ2d@giganews.com>, 
>>KeithDick@earthlink.net says...
>>
>>>JShepherd wrote:
>>>
>>>>In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdnZ2d@giganews.com>, 
>>>>KeithDick@earthlink.net says...
>>>>
>>>>
>>>>>JShepherd wrote:
>>>>>
>>>>>
>>>>>>In article <hgbkvp$emm$2@news.eternal-september.org>, spambait@milmac.com 
>>>>>>says...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>In article <hgbkdd$5te$1@news.eternal-september.org>, invalid@nowhere.com 
>>>>>>
>>>>>>(JShep
>>>>>>
>>>>>>
>>>>>>
>>>>>>>herd) wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>In article 
>>>>>>
>>>>>><85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>chinmay13@gmail.com says...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Hello,
>>>>>>>>>
>>>>>>>>>I have a field
>>>>>>>>>  04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>>>>>I am trying to convert it to unpacked field
>>>>>>>>>  04 FIELD-B                 PIC S9(10)V9(5).
>>>>>>>>>
>>>>>>>>>I am doing
>>>>>>>>>     ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>>>
>>>>>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>>>>>>How to get correct value in FIELD-B?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Seems TNS mode has some sort of issue with that
>>>>>>>>
>>>>>>>>
>>>>>>>>204.1                  move 123.456 to field-a.
>>>>>>>>204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>>
>>>>>>>>
>>>>>>>>TNS mode 
>>>>>>>>
>>>>>>>>-TESTCOB(STEP)-d field-a
>>>>>>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>>>>>>-TESTCOB-d field-b
>>>>>>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>>>>>>
>>>>>>>>Native mode 
>>>>>>>>
>>>>>>>>(eInspect 0,574):p field-a
>>>>>>>>$1 = 0000000123.45600
>>>>>>>>(eInspect 0,574):p field-b
>>>>>>>>$2 = 0000000123.45600
>>>>>>>>
>>>>>>>
>>>>>>>What's the result of a COBOL DISPLAY statement on each field? Are the 
>>
>>fields
>>
>>>>>>>actually corrupt, or is Inspect just displaying them incorrectly?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Same as inspect
>>>>>>Adding the comp-3 to comp works correctly.
>>>>>>
>>>>>
>>>>>I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same as 
>>>>
>>>>Insp
>>>>
>>>>
>>>>>ect does, how can it be that "adding the comp-3 to comp works correctly" be 
>>
>>a 
>>
>>>>tr
>>>>
>>>>
>>>>>ue statement?  If things are working correctly, the two values should be 
> 
> the 
> 
>>>>sam
>>>>
>>>>
>>>>>e, but the Inspect display shows one is 10 times the value of the other.
>>>>>
>>>>>Come to think of it, the original poster's case had no comp fields.  He had 
>>>>
>>>>one 
>>>>
>>>>
>>>>>comp-3 and one display numeric.  Are you using a comp field somewhere in 
>>>>
>>>>there?
>>>>
>>>>
>>>>>As they told us in high school, you haven't shown enough of your work to 
> 
> get 
> 
>>>>ful
>>>>
>>>>
>>>>>l credit. (joke)
>>>>>
>>>>>If you could, please show the declaration of FIELD-A and FIELD-B, put COBOL 
>>>>
>>>>DISP
>>>>
>>>>
>>>>>LAY statements for both FIELD-A and FIELD-B in the program after the ADD 
>>>>
>>>>stateme
>>>>
>>>>
>>>>>nt, show the results of the COBOL DISPLAYs, and show the results of these 
>>>>
>>>>Inspec
>>>>
>>>>
>>>>>t commands:
>>>>>
>>>>> D FIELD-A
>>>>> D FIELD-A WHOLE IN HEX
>>>>> D FIELD-B
>>>>> D FIELD-B WHOLE IN HEX
>>>>>
>>>>>I think that would be enough to show whether COBOL is doing arithmetic with 
>>>>
>>>>comp
>>>>
>>>>
>>>>>-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, 
>>
>>and 
>>
>>>>wh
>>>>
>>>>
>>>>>ether Inspect is displaying comp-3 fields correctly.
>>>>>
>>>>>I think the follow-ups from the original guy showed that, in his example, 
>>>>
>>>>COBOL 
>>>>
>>>>
>>>>>was doing the arithmetic and/or move with the comp-3 field correctly.  
>>
>>Inspect
>>
>>>>w
>>>>
>>>>
>>>>>as displaying his comp-3 field incorrectly.  I believe he did not show us 
>>
>>any 
>>
>>>>CO
>>>>
>>>>
>>>>>BOL DISPLAYs.
>>>>
>>>>
>>>>
>>>>The issue seems to be in TNS mode
>>>>from a COMP-3 field to a usage display field.
>>>>
>>>> 01 packed-stuff.
>>>>    04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>    04 FIELD-B                 PIC S9(10)V9(5).
>>>>    04 FIELD-C                 PIC S9(10)V9(5) comp.
>>>>    04 FIELD-D                 PIC S9(10)V9(5) usage display.
>>>>
>>>> 0000-BEGIN.
>>>>    move 123.456 to field-a.
>>>>    ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>    ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
>>>>    ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
>>>>    display field-a "   // COMP-3".
>>>>    display field-b "   // no usage option".
>>>>    display field-c "   // COMP         ".
>>>>    display field-d "   // Usage display".
>>>>    stop run.
>>>>
>>>>
>>>>TNS mode 
>>>>0000000123.45600   // COMP-3
>>>>0000001234.56000   // no usage option
>>>>0000000123.45600   // COMP
>>>>0000001234.56000   // Usage display
>>>>
>>>>Native mode 
>>>>0000000123.45600   // COMP-3
>>>>0000000123.45600   // no usage option
>>>>0000000123.45600   // COMP
>>>>0000000123.45600   // Usage display
>>>>
>>>>
>>>>
>>>
>>>Ah, now I understand what you are seeing.  Thanks for the additional 
>>
>>information
>>
>>>.  But we need still a little more to be sure exactly where the problem is.  
>>
>>Fro
>>
>>>m the evidence in your post, it seems likely that the problem is that the ADD 
>>
>>pu
>>
>>>ts the wrong result into the display numeric field, but I would like to see 
>>
>>Insp
>>
>>>ect's hex display of the value of all of the fields, just to be sure.
>>>
>>>In the original case from ChinmaYT, the Inspect hex displays showed that the 
>>
>>act
>>
>>>ual values in the variables were correct, so COBOL was working correctly and 
>>
>>the
>>
>>>only problem he had was that Inspect was displaying the value of the comp-3 
>>
>>fie
>>
>>>ld incorrectly when asked to display it normally (not in hex).  You seem to 
>>
>>have
>>
>>>found a different problem if the results of COBOL's DISPLAY can be believed, 
>>
>>an
>>
>>>d it would be very surprising if DISPLAY of a display numeric field wasn't 
>>
>>worki
>>
>>>ng correctly.
>>>
>>>It seems rather odd that in the original case the COBOL statements worked 
>>
>>correc
>>
>>>tly but your case seems to show that COBOL is computing a wrong result.  I 
>>
>>wonde
>>
>>>r whether I misunderstood the evidence from the original case.  I will go 
> 
> look 
> 
>>a
>>
>>>t those posts again.
>>>
>>>If you are willing to do a little more experimenting, I'd like to see the 
>>
>>follow
>>
>>>ing for the TNS mode program:
>>>
>>>Inspect output from D FIELD-x WHOLE IN HEX for all the fields.
>>>
>>>Change the program to replace the ADD statements with simple MOVE statements 
>>
>>fro
>>
>>>m FIELD-A to the other fields and show both the COBOL DISPLAY output and the 
>>
>>Ins
>>
>>>pect display of the hex values for all of the fields.
>>>
>>>You could drop FIELD-D, since USAGE DISPLAY is the default, but if you want 
> 
> to 
> 
>>l
>>
>>>eave it in, that's fine.
>>>
>>>I expect that the optimization level does not affect this, but it would be 
>>
>>best 
>>
>>>to check to see whether specifying OPTIMIZE 0 fixes it.
>>
>>
>>
>>TNS mode Optimization level does not change the result
>>Accelerating the TNS mode object does not change the result
>>
>>---------------------
>>
>>AFTER ADD Zero 
>>
>>-TESTCOB(STEP)-d field-a in hex
>>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>>
>>-TESTCOB-d field-b in hex
>>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 %H35 
>>%H36 %H30 %H30 %H30
>>-TESTCOB-d field-b in a
>>PACKED-STUFF.FIELD-B = "000000123456000"
>>
>>-TESTCOB-d field-c in hex
>>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>>
>>-----------------------
>>After Move 
>>
>>-TESTCOB(STEP)-d field-a in hex
>>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>>-TESTCOB-d field-b in hex
>>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 
>>%H35 %H36 %H30 %H30
>>-TESTCOB-d field-b in a
>>PACKED-STUFF.FIELD-B = "000000012345600"
>>-TESTCOB-d field-c in hex
>>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>>
>>
>>----------------
>>
>>TNS mode ADD zero
>>0000000123.45600   // COMP-3
>>0000001234.56000   // no usage option
>>0000000123.45600   // COMP
>>
>>TNS mode move 
>>0000000123.45600   // COMP-3
>>0000000123.45600   // Move to no usage option
>>0000000123.45600   // move to comp
>>
> 
> 
> 
> COMPUTE works where ADD fails.
> MULTIPLY by 1 works.
> 
>     move 123.456 to field-a.
>     display field-a "   // comp-3 value   ".
>     ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>     display field-b "   // add zero       ".
> 
>     ADD FIELD-A TO 0.0000  GIVING FIELD-B ROUNDED.
>     display field-b "   // add 0.0000     ".
>  
>     ADD FIELD-A TO 1  GIVING FIELD-B ROUNDED.
>     display field-b "   // add 1          ".
>  
>     multiply FIELD-A by 1  GIVING FIELD-B ROUNDED.
>     display field-b "   // multiply by 1      ".
>  
>     compute field-b = field-a + 0
>     display field-b "   // compute field-b = field-a + 0 ".
>  
>     compute field-b = field-a + 1
>     display field-b "   // compute field-b = field-a + 1 ".
>     stop run.
> 
> 0000000123.45600   // comp-3 value
> 0000001234.56000   // add zero
> 0000001234.56000   // add 0.0000
> 0000001244.56000   // add 1
> 0000000123.45600   // multiply by 1
> 0000000123.45600   // compute field-b = field-a + 0
> 0000000124.45600   // compute field-b = field-a + 1
> 

Thanks for the additional investigation.  From what I can tell, the ADD is doing the wrong thing when one of its inputs is comp-3 and its output is display numeric.  The case with ADD 1 seems to show that the problem is not with getting the value of the comp-3 items, but rather with converting the result of the addition to display numeric.  I'm a little suprised that ADD has the problem but MULTIPLY does not.  Interesting.

You definitely have enough evidence to report the problem to GCSC.  Can you make the problem report or get someone you work with to report it?

This is a worse problem than the original guy had.  His only problem was that Inspect displayed comp-3 values incorrectly.  This example shows that COBOL actually is calculating incorrect results.

I wonder why the original guy did not see this problem.  His fields were declared the same as yours and his ADD was the same.  I looked at his posts again, and I still believe that, in his example, ADD put the correct value into the display numeric field.  Maybe you and he have different IPMs of COBOL.  If you don't have the most recent IPM, perhaps this problem was found earlier and fixed in the version he has.  Of course, it could be a recently-introduced problem, so I think it should be reported.

You didn't show Inspect's normal display (not hex) of the comp-3 field.  Does your version of Inspect display the wrong value for the comp-3 field just as his did, or is that different, too?

In article <SOCdnSYrpNHZ6rfWnZ2dnUVZ_sSdnZ2d@giganews.com>, 
KeithDick@earthlink.net says...
>
>JShepherd wrote:
>> In article <hgdpih$sr$1@news.eternal-september.org>, invalid@nowhere.com 
>> says...
>> 
>>>In article <YP2dnSxUUoR2_bfWnZ2dnUVZ_hednZ2d@giganews.com>, 
>>>KeithDick@earthlink.net says...
>>>
>>>>JShepherd wrote:
>>>>
>>>>>In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdnZ2d@giganews.com>, 
>>>>>KeithDick@earthlink.net says...
>>>>>
>>>>>
>>>>>>JShepherd wrote:
>>>>>>
>>>>>>
>>>>>>>In article <hgbkvp$emm$2@news.eternal-september.org>, 
spambait@milmac.com 
>>>>>>>says...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>In article <hgbkdd$5te$1@news.eternal-september.org>, 
invalid@nowhere.com
> 
>>>>>>>
>>>>>>>(JShep
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>herd) wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>In article 
>>>>>>>
>>>>>>><85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>chinmay13@gmail.com says...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Hello,
>>>>>>>>>>
>>>>>>>>>>I have a field
>>>>>>>>>>  04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>>>>>>I am trying to convert it to unpacked field
>>>>>>>>>>  04 FIELD-B                 PIC S9(10)V9(5).
>>>>>>>>>>
>>>>>>>>>>I am doing
>>>>>>>>>>     ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>>>>
>>>>>>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>>>>>>>How to get correct value in FIELD-B?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Seems TNS mode has some sort of issue with that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>204.1                  move 123.456 to field-a.
>>>>>>>>>204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>TNS mode 
>>>>>>>>>
>>>>>>>>>-TESTCOB(STEP)-d field-a
>>>>>>>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>>>>>>>-TESTCOB-d field-b
>>>>>>>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>>>>>>>
>>>>>>>>>Native mode 
>>>>>>>>>
>>>>>>>>>(eInspect 0,574):p field-a
>>>>>>>>>$1 = 0000000123.45600
>>>>>>>>>(eInspect 0,574):p field-b
>>>>>>>>>$2 = 0000000123.45600
>>>>>>>>>
>>>>>>>>
>>>>>>>>What's the result of a COBOL DISPLAY statement on each field? Are the 
>>>
>>>fields
>>>
>>>>>>>>actually corrupt, or is Inspect just displaying them incorrectly?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Same as inspect
>>>>>>>Adding the comp-3 to comp works correctly.
>>>>>>>
>>>>>>
>>>>>>I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same 
as
> 
>>>>>
>>>>>Insp
>>>>>
>>>>>
>>>>>>ect does, how can it be that "adding the comp-3 to comp works correctly" 
be
> 
>>>
>>>a 
>>>
>>>>>tr
>>>>>
>>>>>
>>>>>>ue statement?  If things are working correctly, the two values should be 
>> 
>> the 
>> 
>>>>>sam
>>>>>
>>>>>
>>>>>>e, but the Inspect display shows one is 10 times the value of the other.
>>>>>>
>>>>>>Come to think of it, the original poster's case had no comp fields.  He 
had
> 
>>>>>
>>>>>one 
>>>>>
>>>>>
>>>>>>comp-3 and one display numeric.  Are you using a comp field somewhere in 
>>>>>
>>>>>there?
>>>>>
>>>>>
>>>>>>As they told us in high school, you haven't shown enough of your work to 
>> 
>> get 
>> 
>>>>>ful
>>>>>
>>>>>
>>>>>>l credit. (joke)
>>>>>>
>>>>>>If you could, please show the declaration of FIELD-A and FIELD-B, put 
COBOL
> 
>>>>>
>>>>>DISP
>>>>>
>>>>>
>>>>>>LAY statements for both FIELD-A and FIELD-B in the program after the ADD 
>>>>>
>>>>>stateme
>>>>>
>>>>>
>>>>>>nt, show the results of the COBOL DISPLAYs, and show the results of these 
>>>>>
>>>>>Inspec
>>>>>
>>>>>
>>>>>>t commands:
>>>>>>
>>>>>> D FIELD-A
>>>>>> D FIELD-A WHOLE IN HEX
>>>>>> D FIELD-B
>>>>>> D FIELD-B WHOLE IN HEX
>>>>>>
>>>>>>I think that would be enough to show whether COBOL is doing arithmetic 
with
> 
>>>>>
>>>>>comp
>>>>>
>>>>>
>>>>>>-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, 
>>>
>>>and 
>>>
>>>>>wh
>>>>>
>>>>>
>>>>>>ether Inspect is displaying comp-3 fields correctly.
>>>>>>
>>>>>>I think the follow-ups from the original guy showed that, in his example, 
>>>>>
>>>>>COBOL 
>>>>>
>>>>>
>>>>>>was doing the arithmetic and/or move with the comp-3 field correctly.  
>>>
>>>Inspect
>>>
>>>>>w
>>>>>
>>>>>
>>>>>>as displaying his comp-3 field incorrectly.  I believe he did not show us 
>>>
>>>any 
>>>
>>>>>CO
>>>>>
>>>>>
>>>>>>BOL DISPLAYs.
>>>>>
>>>>>
>>>>>
>>>>>The issue seems to be in TNS mode
>>>>>from a COMP-3 field to a usage display field.
>>>>>
>>>>> 01 packed-stuff.
>>>>>    04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>    04 FIELD-B                 PIC S9(10)V9(5).
>>>>>    04 FIELD-C                 PIC S9(10)V9(5) comp.
>>>>>    04 FIELD-D                 PIC S9(10)V9(5) usage display.
>>>>>
>>>>> 0000-BEGIN.
>>>>>    move 123.456 to field-a.
>>>>>    ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>    ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
>>>>>    ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
>>>>>    display field-a "   // COMP-3".
>>>>>    display field-b "   // no usage option".
>>>>>    display field-c "   // COMP         ".
>>>>>    display field-d "   // Usage display".
>>>>>    stop run.
>>>>>
>>>>>
>>>>>TNS mode 
>>>>>0000000123.45600   // COMP-3
>>>>>0000001234.56000   // no usage option
>>>>>0000000123.45600   // COMP
>>>>>0000001234.56000   // Usage display
>>>>>
>>>>>Native mode 
>>>>>0000000123.45600   // COMP-3
>>>>>0000000123.45600   // no usage option
>>>>>0000000123.45600   // COMP
>>>>>0000000123.45600   // Usage display
>>>>>
>>>>>
>>>>>
>>>>
>>>>Ah, now I understand what you are seeing.  Thanks for the additional 
>>>
>>>information
>>>
>>>>.  But we need still a little more to be sure exactly where the problem is. 
 
>>>
>>>Fro
>>>
>>>>m the evidence in your post, it seems likely that the problem is that the 
ADD
> 
>>>
>>>pu
>>>
>>>>ts the wrong result into the display numeric field, but I would like to see 
>>>
>>>Insp
>>>
>>>>ect's hex display of the value of all of the fields, just to be sure.
>>>>
>>>>In the original case from ChinmaYT, the Inspect hex displays showed that 
the 
>>>
>>>act
>>>
>>>>ual values in the variables were correct, so COBOL was working correctly 
and 
>>>
>>>the
>>>
>>>>only problem he had was that Inspect was displaying the value of the comp-3 
>>>
>>>fie
>>>
>>>>ld incorrectly when asked to display it normally (not in hex).  You seem to 
>>>
>>>have
>>>
>>>>found a different problem if the results of COBOL's DISPLAY can be 
believed, 
>>>
>>>an
>>>
>>>>d it would be very surprising if DISPLAY of a display numeric field wasn't 
>>>
>>>worki
>>>
>>>>ng correctly.
>>>>
>>>>It seems rather odd that in the original case the COBOL statements worked 
>>>
>>>correc
>>>
>>>>tly but your case seems to show that COBOL is computing a wrong result.  I 
>>>
>>>wonde
>>>
>>>>r whether I misunderstood the evidence from the original case.  I will go 
>> 
>> look 
>> 
>>>a
>>>
>>>>t those posts again.
>>>>
>>>>If you are willing to do a little more experimenting, I'd like to see the 
>>>
>>>follow
>>>
>>>>ing for the TNS mode program:
>>>>
>>>>Inspect output from D FIELD-x WHOLE IN HEX for all the fields.
>>>>
>>>>Change the program to replace the ADD statements with simple MOVE 
statements 
>>>
>>>fro
>>>
>>>>m FIELD-A to the other fields and show both the COBOL DISPLAY output and 
the 
>>>
>>>Ins
>>>
>>>>pect display of the hex values for all of the fields.
>>>>
>>>>You could drop FIELD-D, since USAGE DISPLAY is the default, but if you want 
>> 
>> to 
>> 
>>>l
>>>
>>>>eave it in, that's fine.
>>>>
>>>>I expect that the optimization level does not affect this, but it would be 
>>>
>>>best 
>>>
>>>>to check to see whether specifying OPTIMIZE 0 fixes it.
>>>
>>>
>>>
>>>TNS mode Optimization level does not change the result
>>>Accelerating the TNS mode object does not change the result
>>>
>>>---------------------
>>>
>>>AFTER ADD Zero 
>>>
>>>-TESTCOB(STEP)-d field-a in hex
>>>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>>>
>>>-TESTCOB-d field-b in hex
>>>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 
%H35 
>>>%H36 %H30 %H30 %H30
>>>-TESTCOB-d field-b in a
>>>PACKED-STUFF.FIELD-B = "000000123456000"
>>>
>>>-TESTCOB-d field-c in hex
>>>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>>>
>>>-----------------------
>>>After Move 
>>>
>>>-TESTCOB(STEP)-d field-a in hex
>>>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>>>-TESTCOB-d field-b in hex
>>>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 
%H34 
>>>%H35 %H36 %H30 %H30
>>>-TESTCOB-d field-b in a
>>>PACKED-STUFF.FIELD-B = "000000012345600"
>>>-TESTCOB-d field-c in hex
>>>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>>>
>>>
>>>----------------
>>>
>>>TNS mode ADD zero
>>>0000000123.45600   // COMP-3
>>>0000001234.56000   // no usage option
>>>0000000123.45600   // COMP
>>>
>>>TNS mode move 
>>>0000000123.45600   // COMP-3
>>>0000000123.45600   // Move to no usage option
>>>0000000123.45600   // move to comp
>>>
>> 
>> 
>> 
>> COMPUTE works where ADD fails.
>> MULTIPLY by 1 works.
>> 
>>     move 123.456 to field-a.
>>     display field-a "   // comp-3 value   ".
>>     ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>     display field-b "   // add zero       ".
>> 
>>     ADD FIELD-A TO 0.0000  GIVING FIELD-B ROUNDED.
>>     display field-b "   // add 0.0000     ".
>>  
>>     ADD FIELD-A TO 1  GIVING FIELD-B ROUNDED.
>>     display field-b "   // add 1          ".
>>  
>>     multiply FIELD-A by 1  GIVING FIELD-B ROUNDED.
>>     display field-b "   // multiply by 1      ".
>>  
>>     compute field-b = field-a + 0
>>     display field-b "   // compute field-b = field-a + 0 ".
>>  
>>     compute field-b = field-a + 1
>>     display field-b "   // compute field-b = field-a + 1 ".
>>     stop run.
>> 
>> 0000000123.45600   // comp-3 value
>> 0000001234.56000   // add zero
>> 0000001234.56000   // add 0.0000
>> 0000001244.56000   // add 1
>> 0000000123.45600   // multiply by 1
>> 0000000123.45600   // compute field-b = field-a + 0
>> 0000000124.45600   // compute field-b = field-a + 1
>> 
>
>Thanks for the additional investigation.  From what I can tell, the ADD is 
doing
> the wrong thing when one of its inputs is comp-3 and its output is display 
nume
>ric.  The case with ADD 1 seems to show that the problem is not with getting 
the
> value of the comp-3 items, but rather with converting the result of the 
additio
>n to display numeric.  I'm a little suprised that ADD has the problem but 
MULTIP
>LY does not.  Interesting.
>
>You definitely have enough evidence to report the problem to GCSC.  Can you 
make
> the problem report or get someone you work with to report it?
>
>This is a worse problem than the original guy had.  His only problem was that 
In
>spect displayed comp-3 values incorrectly.  This example shows that COBOL 
actual
>ly is calculating incorrect results.
>
>I wonder why the original guy did not see this problem.  His fields were 
declare
>d the same as yours and his ADD was the same.  I looked at his posts again, 
and 
>I still believe that, in his example, ADD put the correct value into the 
display
> numeric field.  Maybe you and he have different IPMs of COBOL.  If you don't 
ha
>ve the most recent IPM, perhaps this problem was found earlier and fixed in 
the 
>version he has.  Of course, it could be a recently-introduced problem, so I 
thin
>k it should be reported.
>
>You didn't show Inspect's normal display (not hex) of the comp-3 field.  Does 
yo
>ur version of Inspect display the wrong value for the comp-3 field just as his 
d
>id, or is that different, too?


-TESTCOB-d field-a
PACKED-STUFF.FIELD-A =        +123.45600

My testing was done on H06.16

The results are the same on G06.32 and J06.06

JShepherd wrote:
> In article <SOCdnSYrpNHZ6rfWnZ2dnUVZ_sSdnZ2d@giganews.com>, 
> KeithDick@earthlink.net says...
> 
>>JShepherd wrote:
>>
>>>In article <hgdpih$sr$1@news.eternal-september.org>, invalid@nowhere.com 
>>>says...
>>>
>>>
>>>>In article <YP2dnSxUUoR2_bfWnZ2dnUVZ_hednZ2d@giganews.com>, 
>>>>KeithDick@earthlink.net says...
>>>>
>>>>
>>>>>JShepherd wrote:
>>>>>
>>>>>
>>>>>>In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdnZ2d@giganews.com>, 
>>>>>>KeithDick@earthlink.net says...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>JShepherd wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>In article <hgbkvp$emm$2@news.eternal-september.org>, 
> 
> spambait@milmac.com 
> 
>>>>>>>>says...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>In article <hgbkdd$5te$1@news.eternal-september.org>, 
> 
> invalid@nowhere.com
> 
>>>>>>>>(JShep
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>herd) wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>In article 
>>>>>>>>
>>>>>>>><85416422-38fc-4916-9a71-083e0aa8f69f@f16g2000yqm.googlegroups.com>,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>chinmay13@gmail.com says...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Hello,
>>>>>>>>>>>
>>>>>>>>>>>I have a field
>>>>>>>>>>> 04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>>>>>>>I am trying to convert it to unpacked field
>>>>>>>>>>> 04 FIELD-B                 PIC S9(10)V9(5).
>>>>>>>>>>>
>>>>>>>>>>>I am doing
>>>>>>>>>>>    ADD  FIELD-A           TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>>>>>
>>>>>>>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult 1000.
>>>>>>>>>>>How to get correct value in FIELD-B?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Seems TNS mode has some sort of issue with that
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>204.1                  move 123.456 to field-a.
>>>>>>>>>>204.2                  ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>TNS mode 
>>>>>>>>>>
>>>>>>>>>>-TESTCOB(STEP)-d field-a
>>>>>>>>>>PACKED-STUFF.FIELD-A =        +123.45600
>>>>>>>>>>-TESTCOB-d field-b
>>>>>>>>>>PACKED-STUFF.FIELD-B =       1234.56000
>>>>>>>>>>
>>>>>>>>>>Native mode 
>>>>>>>>>>
>>>>>>>>>>(eInspect 0,574):p field-a
>>>>>>>>>>$1 = 0000000123.45600
>>>>>>>>>>(eInspect 0,574):p field-b
>>>>>>>>>>$2 = 0000000123.45600
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>What's the result of a COBOL DISPLAY statement on each field? Are the 
>>>>
>>>>fields
>>>>
>>>>
>>>>>>>>>actually corrupt, or is Inspect just displaying them incorrectly?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Same as inspect
>>>>>>>>Adding the comp-3 to comp works correctly.
>>>>>>>>
>>>>>>>
>>>>>>>I'm sorry, but I don't understand this.  If COBOL DISPLAY shows the same 
> 
> as
> 
>>>>>>Insp
>>>>>>
>>>>>>
>>>>>>
>>>>>>>ect does, how can it be that "adding the comp-3 to comp works correctly" 
> 
> be
> 
>>>>a 
>>>>
>>>>
>>>>>>tr
>>>>>>
>>>>>>
>>>>>>
>>>>>>>ue statement?  If things are working correctly, the two values should be 
>>>
>>>the 
>>>
>>>
>>>>>>sam
>>>>>>
>>>>>>
>>>>>>
>>>>>>>e, but the Inspect display shows one is 10 times the value of the other.
>>>>>>>
>>>>>>>Come to think of it, the original poster's case had no comp fields.  He 
> 
> had
> 
>>>>>>one 
>>>>>>
>>>>>>
>>>>>>
>>>>>>>comp-3 and one display numeric.  Are you using a comp field somewhere in 
>>>>>>
>>>>>>there?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>As they told us in high school, you haven't shown enough of your work to 
>>>
>>>get 
>>>
>>>
>>>>>>ful
>>>>>>
>>>>>>
>>>>>>
>>>>>>>l credit. (joke)
>>>>>>>
>>>>>>>If you could, please show the declaration of FIELD-A and FIELD-B, put 
> 
> COBOL
> 
>>>>>>DISP
>>>>>>
>>>>>>
>>>>>>
>>>>>>>LAY statements for both FIELD-A and FIELD-B in the program after the ADD 
>>>>>>
>>>>>>stateme
>>>>>>
>>>>>>
>>>>>>
>>>>>>>nt, show the results of the COBOL DISPLAYs, and show the results of these 
>>>>>>
>>>>>>Inspec
>>>>>>
>>>>>>
>>>>>>
>>>>>>>t commands:
>>>>>>>
>>>>>>>D FIELD-A
>>>>>>>D FIELD-A WHOLE IN HEX
>>>>>>>D FIELD-B
>>>>>>>D FIELD-B WHOLE IN HEX
>>>>>>>
>>>>>>>I think that would be enough to show whether COBOL is doing arithmetic 
> 
> with
> 
>>>>>>comp
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-3 fields correctly, whether COBOL is displaying comp-3 fields correctly, 
>>>>
>>>>and 
>>>>
>>>>
>>>>>>wh
>>>>>>
>>>>>>
>>>>>>
>>>>>>>ether Inspect is displaying comp-3 fields correctly.
>>>>>>>
>>>>>>>I think the follow-ups from the original guy showed that, in his example, 
>>>>>>
>>>>>>COBOL 
>>>>>>
>>>>>>
>>>>>>
>>>>>>>was doing the arithmetic and/or move with the comp-3 field correctly.  
>>>>
>>>>Inspect
>>>>
>>>>
>>>>>>w
>>>>>>
>>>>>>
>>>>>>
>>>>>>>as displaying his comp-3 field incorrectly.  I believe he did not show us 
>>>>
>>>>any 
>>>>
>>>>
>>>>>>CO
>>>>>>
>>>>>>
>>>>>>
>>>>>>>BOL DISPLAYs.
>>>>>>
>>>>>>
>>>>>>
>>>>>>The issue seems to be in TNS mode
>>>>>
>>>>>>from a COMP-3 field to a usage display field.
>>>>>
>>>>>>01 packed-stuff.
>>>>>>   04 FIELD-A                 PIC S9(10)V9(5) COMP-3.
>>>>>>   04 FIELD-B                 PIC S9(10)V9(5).
>>>>>>   04 FIELD-C                 PIC S9(10)V9(5) comp.
>>>>>>   04 FIELD-D                 PIC S9(10)V9(5) usage display.
>>>>>>
>>>>>>0000-BEGIN.
>>>>>>   move 123.456 to field-a.
>>>>>>   ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>>>>   ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
>>>>>>   ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
>>>>>>   display field-a "   // COMP-3".
>>>>>>   display field-b "   // no usage option".
>>>>>>   display field-c "   // COMP         ".
>>>>>>   display field-d "   // Usage display".
>>>>>>   stop run.
>>>>>>
>>>>>>
>>>>>>TNS mode 
>>>>>>0000000123.45600   // COMP-3
>>>>>>0000001234.56000   // no usage option
>>>>>>0000000123.45600   // COMP
>>>>>>0000001234.56000   // Usage display
>>>>>>
>>>>>>Native mode 
>>>>>>0000000123.45600   // COMP-3
>>>>>>0000000123.45600   // no usage option
>>>>>>0000000123.45600   // COMP
>>>>>>0000000123.45600   // Usage display
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>Ah, now I understand what you are seeing.  Thanks for the additional 
>>>>
>>>>information
>>>>
>>>>
>>>>>.  But we need still a little more to be sure exactly where the problem is. 
> 
>  
> 
>>>>Fro
>>>>
>>>>
>>>>>m the evidence in your post, it seems likely that the problem is that the 
> 
> ADD
> 
>>>>pu
>>>>
>>>>
>>>>>ts the wrong result into the display numeric field, but I would like to see 
>>>>
>>>>Insp
>>>>
>>>>
>>>>>ect's hex display of the value of all of the fields, just to be sure.
>>>>>
>>>>>In the original case from ChinmaYT, the Inspect hex displays showed that 
> 
> the 
> 
>>>>act
>>>>
>>>>
>>>>>ual values in the variables were correct, so COBOL was working correctly 
> 
> and 
> 
>>>>the
>>>>
>>>>
>>>>>only problem he had was that Inspect was displaying the value of the comp-3 
>>>>
>>>>fie
>>>>
>>>>
>>>>>ld incorrectly when asked to display it normally (not in hex).  You seem to 
>>>>
>>>>have
>>>>
>>>>
>>>>>found a different problem if the results of COBOL's DISPLAY can be 
> 
> believed, 
> 
>>>>an
>>>>
>>>>
>>>>>d it would be very surprising if DISPLAY of a display numeric field wasn't 
>>>>
>>>>worki
>>>>
>>>>
>>>>>ng correctly.
>>>>>
>>>>>It seems rather odd that in the original case the COBOL statements worked 
>>>>
>>>>correc
>>>>
>>>>
>>>>>tly but your case seems to show that COBOL is computing a wrong result.  I 
>>>>
>>>>wonde
>>>>
>>>>
>>>>>r whether I misunderstood the evidence from the original case.  I will go 
>>>
>>>look 
>>>
>>>
>>>>a
>>>>
>>>>
>>>>>t those posts again.
>>>>>
>>>>>If you are willing to do a little more experimenting, I'd like to see the 
>>>>
>>>>follow
>>>>
>>>>
>>>>>ing for the TNS mode program:
>>>>>
>>>>>Inspect output from D FIELD-x WHOLE IN HEX for all the fields.
>>>>>
>>>>>Change the program to replace the ADD statements with simple MOVE 
> 
> statements 
> 
>>>>fro
>>>>
>>>>
>>>>>m FIELD-A to the other fields and show both the COBOL DISPLAY output and 
> 
> the 
> 
>>>>Ins
>>>>
>>>>
>>>>>pect display of the hex values for all of the fields.
>>>>>
>>>>>You could drop FIELD-D, since USAGE DISPLAY is the default, but if you want 
>>>
>>>to 
>>>
>>>
>>>>l
>>>>
>>>>
>>>>>eave it in, that's fine.
>>>>>
>>>>>I expect that the optimization level does not affect this, but it would be 
>>>>
>>>>best 
>>>>
>>>>
>>>>>to check to see whether specifying OPTIMIZE 0 fixes it.
>>>>
>>>>
>>>>
>>>>TNS mode Optimization level does not change the result
>>>>Accelerating the TNS mode object does not change the result
>>>>
>>>>---------------------
>>>>
>>>>AFTER ADD Zero 
>>>>
>>>>-TESTCOB(STEP)-d field-a in hex
>>>>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>>>>
>>>>-TESTCOB-d field-b in hex
>>>>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 %H34 
> 
> %H35 
> 
>>>>%H36 %H30 %H30 %H30
>>>>-TESTCOB-d field-b in a
>>>>PACKED-STUFF.FIELD-B = "000000123456000"
>>>>
>>>>-TESTCOB-d field-c in hex
>>>>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>>>>
>>>>-----------------------
>>>>After Move 
>>>>
>>>>-TESTCOB(STEP)-d field-a in hex
>>>>PACKED-STUFF.FIELD-A = 0 0 0 1 %H23 %H45 %H60 %HC
>>>>-TESTCOB-d field-b in hex
>>>>PACKED-STUFF.FIELD-B = %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 
> 
> %H34 
> 
>>>>%H35 %H36 %H30 %H30
>>>>-TESTCOB-d field-b in a
>>>>PACKED-STUFF.FIELD-B = "000000012345600"
>>>>-TESTCOB-d field-c in hex
>>>>PACKED-STUFF.FIELD-C = 0 0 %HBC %H6100
>>>>
>>>>
>>>>----------------
>>>>
>>>>TNS mode ADD zero
>>>>0000000123.45600   // COMP-3
>>>>0000001234.56000   // no usage option
>>>>0000000123.45600   // COMP
>>>>
>>>>TNS mode move 
>>>>0000000123.45600   // COMP-3
>>>>0000000123.45600   // Move to no usage option
>>>>0000000123.45600   // move to comp
>>>>
>>>
>>>
>>>
>>>COMPUTE works where ADD fails.
>>>MULTIPLY by 1 works.
>>>
>>>    move 123.456 to field-a.
>>>    display field-a "   // comp-3 value   ".
>>>    ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
>>>    display field-b "   // add zero       ".
>>>
>>>    ADD FIELD-A TO 0.0000  GIVING FIELD-B ROUNDED.
>>>    display field-b "   // add 0.0000     ".
>>> 
>>>    ADD FIELD-A TO 1  GIVING FIELD-B ROUNDED.
>>>    display field-b "   // add 1          ".
>>> 
>>>    multiply FIELD-A by 1  GIVING FIELD-B ROUNDED.
>>>    display field-b "   // multiply by 1      ".
>>> 
>>>    compute field-b = field-a + 0
>>>    display field-b "   // compute field-b = field-a + 0 ".
>>> 
>>>    compute field-b = field-a + 1
>>>    display field-b "   // compute field-b = field-a + 1 ".
>>>    stop run.
>>>
>>>0000000123.45600   // comp-3 value
>>>0000001234.56000   // add zero
>>>0000001234.56000   // add 0.0000
>>>0000001244.56000   // add 1
>>>0000000123.45600   // multiply by 1
>>>0000000123.45600   // compute field-b = field-a + 0
>>>0000000124.45600   // compute field-b = field-a + 1
>>>
>>
>>Thanks for the additional investigation.  From what I can tell, the ADD is 
> 
> doing
> 
>>the wrong thing when one of its inputs is comp-3 and its output is display 
> 
> nume
> 
>>ric.  The case with ADD 1 seems to show that the problem is not with getting 
> 
> the
> 
>>value of the comp-3 items, but rather with converting the result of the 
> 
> additio
> 
>>n to display numeric.  I'm a little suprised that ADD has the problem but 
> 
> MULTIP
> 
>>LY does not.  Interesting.
>>
>>You definitely have enough evidence to report the problem to GCSC.  Can you 
> 
> make
> 
>>the problem report or get someone you work with to report it?
>>
>>This is a worse problem than the original guy had.  His only problem was that 
> 
> In
> 
>>spect displayed comp-3 values incorrectly.  This example shows that COBOL 
> 
> actual
> 
>>ly is calculating incorrect results.
>>
>>I wonder why the original guy did not see this problem.  His fields were 
> 
> declare
> 
>>d the same as yours and his ADD was the same.  I looked at his posts again, 
> 
> and 
> 
>>I still believe that, in his example, ADD put the correct value into the 
> 
> display
> 
>>numeric field.  Maybe you and he have different IPMs of COBOL.  If you don't 
> 
> ha
> 
>>ve the most recent IPM, perhaps this problem was found earlier and fixed in 
> 
> the 
> 
>>version he has.  Of course, it could be a recently-introduced problem, so I 
> 
> thin
> 
>>k it should be reported.
>>
>>You didn't show Inspect's normal display (not hex) of the comp-3 field.  Does 
> 
> yo
> 
>>ur version of Inspect display the wrong value for the comp-3 field just as his 
> 
> d
> 
>>id, or is that different, too?
> 
> 
> 
> -TESTCOB-d field-a
> PACKED-STUFF.FIELD-A =        +123.45600
> 
> My testing was done on H06.16
> 
> The results are the same on G06.32 and J06.06
> 
> 

Okay, so your Inspect doesn't have the problem displaying comp-3, and your COBOL gets wrong result for ADD from comp-3 to display numeric.

The original guy, ChinmaYT, had exactly the opposite: Inspect displays incorrect value for comp-3, but the ADD gets the right result.

I hope each of you submits a problem report to GCSC about the problem you see on your system.

I have one another doubt regarding COMP-3 field.

I am reading a file data in COMP-3 field.

If the file is in EBCDIC, i am getting correct value in COMP-3 field
and if it is in ASCII, the wrong value gets moved.

Why is it so, does COMP-3 stores in EBCDIC?

On Dec 18 2009, 5:35=A0am, inva...@nowhere.com (JShepherd) wrote:
> In article <SOCdnSYrpNHZ6rfWnZ2dnUVZ_sSdn...@giganews.com>,
> KeithD...@earthlink.net says...
>
>
>
> >JShepherd wrote:
> >> In article <hgdpih$s...@news.eternal-september.org>, inva...@nowhere.c=
om
> >> says...
>
> >>>In article <YP2dnSxUUoR2_bfWnZ2dnUVZ_hedn...@giganews.com>,
> >>>KeithD...@earthlink.net says...
>
> >>>>JShepherd wrote:
>
> >>>>>In article <opCdnf_OMPGeJrTWnZ2dnUVZ_gmdn...@giganews.com>,
> >>>>>KeithD...@earthlink.net says...
>
> >>>>>>JShepherd wrote:
>
> >>>>>>>In article <hgbkvp$em...@news.eternal-september.org>,
>
> spamb...@milmac.com>>>>>>>says...
>
> >>>>>>>>In article <hgbkdd$5t...@news.eternal-september.org>,
>
> inva...@nowhere.com
>
>
>
>
>
> >>>>>>>(JShep
>
> >>>>>>>>herd) wrote:
>
> >>>>>>>>>In article
>
> >>>>>>><85416422-38fc-4916-9a71-083e0aa8f...@f16g2000yqm.googlegroups.com=
>,
>
> >>>>>>>>>chinma...@gmail.com says...
>
> >>>>>>>>>>Hello,
>
> >>>>>>>>>>I have a field
> >>>>>>>>>> =A004 FIELD-A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PIC S9(10)V9(5) =
COMP-3.
> >>>>>>>>>>I am trying to convert it to unpacked field
> >>>>>>>>>> =A004 FIELD-B =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PIC S9(10)V9(5).
>
> >>>>>>>>>>I am doing
> >>>>>>>>>> =A0 =A0 ADD =A0FIELD-A =A0 =A0 =A0 =A0 =A0 TO ZERO GIVING FIEL=
D-B ROUNDED.
>
> >>>>>>>>>>The problem is, whatever i get value in FIELD-B is FIELD-A mult=
 1000.
> >>>>>>>>>>How to get correct value in FIELD-B?
>
> >>>>>>>>>Seems TNS mode has some sort of issue with that
>
> >>>>>>>>>204.1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0move 123.456 to field-a=
..
> >>>>>>>>>204.2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ADD FIELD-A TO ZERO GIV=
ING FIELD-B ROUNDED.
>
> >>>>>>>>>TNS mode
>
> >>>>>>>>>-TESTCOB(STEP)-d field-a
> >>>>>>>>>PACKED-STUFF.FIELD-A =3D =A0 =A0 =A0 =A0+123.45600
> >>>>>>>>>-TESTCOB-d field-b
> >>>>>>>>>PACKED-STUFF.FIELD-B =3D =A0 =A0 =A0 1234.56000
>
> >>>>>>>>>Native mode
>
> >>>>>>>>>(eInspect 0,574):p field-a
> >>>>>>>>>$1 =3D 0000000123.45600
> >>>>>>>>>(eInspect 0,574):p field-b
> >>>>>>>>>$2 =3D 0000000123.45600
>
> >>>>>>>>What's the result of a COBOL DISPLAY statement on each field? Are=
 the
>
> >>>fields
>
> >>>>>>>>actually corrupt, or is Inspect just displaying them incorrectly?
>
> >>>>>>>Same as inspect
> >>>>>>>Adding the comp-3 to comp works correctly.
>
> >>>>>>I'm sorry, but I don't understand this. =A0If COBOL DISPLAY shows t=
he same
> as
>
> >>>>>Insp
>
> >>>>>>ect does, how can it be that "adding the comp-3 to comp works corre=
ctly"
> be
>
> >>>a
>
> >>>>>tr
>
> >>>>>>ue statement? =A0If things are working correctly, the two values sh=
ould be
>
> >> the
>
> >>>>>sam
>
> >>>>>>e, but the Inspect display shows one is 10 times the value of the o=
ther.
>
> >>>>>>Come to think of it, the original poster's case had no comp fields.=
 =A0He
> had
>
> >>>>>one
>
> >>>>>>comp-3 and one display numeric. =A0Are you using a comp field somew=
here in
>
> >>>>>there?
>
> >>>>>>As they told us in high school, you haven't shown enough of your wo=
rk to
>
> >> get
>
> >>>>>ful
>
> >>>>>>l credit. (joke)
>
> >>>>>>If you could, please show the declaration of FIELD-A and FIELD-B, p=
ut
> COBOL
>
> >>>>>DISP
>
> >>>>>>LAY statements for both FIELD-A and FIELD-B in the program after th=
e ADD
>
> >>>>>stateme
>
> >>>>>>nt, show the results of the COBOL DISPLAYs, and show the results of=
 these
>
> >>>>>Inspec
>
> >>>>>>t commands:
>
> >>>>>> D FIELD-A
> >>>>>> D FIELD-A WHOLE IN HEX
> >>>>>> D FIELD-B
> >>>>>> D FIELD-B WHOLE IN HEX
>
> >>>>>>I think that would be enough to show whether COBOL is doing arithme=
tic
> with
>
> >>>>>comp
>
> >>>>>>-3 fields correctly, whether COBOL is displaying comp-3 fields corr=
ectly,
>
> >>>and
>
> >>>>>wh
>
> >>>>>>ether Inspect is displaying comp-3 fields correctly.
>
> >>>>>>I think the follow-ups from the original guy showed that, in his ex=
ample,
>
> >>>>>COBOL
>
> >>>>>>was doing the arithmetic and/or move with the comp-3 field correctl=
y. =A0
>
> >>>Inspect
>
> >>>>>w
>
> >>>>>>as displaying his comp-3 field incorrectly. =A0I believe he did not=
 show us
>
> >>>any
>
> >>>>>CO
>
> >>>>>>BOL DISPLAYs.
>
> >>>>>The issue seems to be in TNS mode
> >>>>>from a COMP-3 field to a usage display field.
>
> >>>>> 01 packed-stuff.
> >>>>> =A0 =A004 FIELD-A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PIC S9(10)V9(5) C=
OMP-3.
> >>>>> =A0 =A004 FIELD-B =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PIC S9(10)V9(5).
> >>>>> =A0 =A004 FIELD-C =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PIC S9(10)V9(5) c=
omp.
> >>>>> =A0 =A004 FIELD-D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PIC S9(10)V9(5) u=
sage display.
>
> >>>>> 0000-BEGIN.
> >>>>> =A0 =A0move 123.456 to field-a.
> >>>>> =A0 =A0ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
> >>>>> =A0 =A0ADD FIELD-A TO ZERO GIVING FIELD-C ROUNDED.
> >>>>> =A0 =A0ADD FIELD-A TO ZERO GIVING FIELD-D ROUNDED.
> >>>>> =A0 =A0display field-a " =A0 // COMP-3".
> >>>>> =A0 =A0display field-b " =A0 // no usage option".
> >>>>> =A0 =A0display field-c " =A0 // COMP =A0 =A0 =A0 =A0 ".
> >>>>> =A0 =A0display field-d " =A0 // Usage display".
> >>>>> =A0 =A0stop run.
>
> >>>>>TNS mode
> >>>>>0000000123.45600 =A0 // COMP-3
> >>>>>0000001234.56000 =A0 // no usage option
> >>>>>0000000123.45600 =A0 // COMP
> >>>>>0000001234.56000 =A0 // Usage display
>
> >>>>>Native mode
> >>>>>0000000123.45600 =A0 // COMP-3
> >>>>>0000000123.45600 =A0 // no usage option
> >>>>>0000000123.45600 =A0 // COMP
> >>>>>0000000123.45600 =A0 // Usage display
>
> >>>>Ah, now I understand what you are seeing. =A0Thanks for the additiona=
l
>
> >>>information
>
> >>>>. =A0But we need still a little more to be sure exactly where the pro=
blem is.
>
> >>>Fro
>
> >>>>m the evidence in your post, it seems likely that the problem is that=
 the
> ADD
>
> >>>pu
>
> >>>>ts the wrong result into the display numeric field, but I would like =
to see
>
> >>>Insp
>
> >>>>ect's hex display of the value of all of the fields, just to be sure.
>
> >>>>In the original case from ChinmaYT, the Inspect hex displays showed t=
hat
> the
>
> >>>act
>
> >>>>ual values in the variables were correct, so COBOL was working correc=
tly
> and
>
> >>>the
>
> >>>>only problem he had was that Inspect was displaying the value of the =
comp-3
>
> >>>fie
>
> >>>>ld incorrectly when asked to display it normally (not in hex). =A0You=
 seem to
>
> >>>have
>
> >>>>found a different problem if the results of COBOL's DISPLAY can be
> believed,
>
> >>>an
>
> >>>>d it would be very surprising if DISPLAY of a display numeric field w=
asn't
>
> >>>worki
>
> >>>>ng correctly.
>
> >>>>It seems rather odd that in the original case the COBOL statements wo=
rked
>
> >>>correc
>
> >>>>tly but your case seems to show that COBOL is computing a wrong resul=
t. =A0I
>
> >>>wonde
>
> >>>>r whether I misunderstood the evidence from the original case. =A0I w=
ill go
>
> >> look
>
> >>>a
>
> >>>>t those posts again.
>
> >>>>If you are willing to do a little more experimenting, I'd like to see=
 the
>
> >>>follow
>
> >>>>ing for the TNS mode program:
>
> >>>>Inspect output from D FIELD-x WHOLE IN HEX for all the fields.
>
> >>>>Change the program to replace the ADD statements with simple MOVE
> statements
>
> >>>fro
>
> >>>>m FIELD-A to the other fields and show both the COBOL DISPLAY output =
and
> the
>
> >>>Ins
>
> >>>>pect display of the hex values for all of the fields.
>
> >>>>You could drop FIELD-D, since USAGE DISPLAY is the default, but if yo=
u want
>
> >> to
>
> >>>l
>
> >>>>eave it in, that's fine.
>
> >>>>I expect that the optimization level does not affect this, but it wou=
ld be
>
> >>>best
>
> >>>>to check to see whether specifying OPTIMIZE 0 fixes it.
>
> >>>TNS mode Optimization level does not change the result
> >>>Accelerating the TNS mode object does not change the result
>
> >>>---------------------
>
> >>>AFTER ADD Zero
>
> >>>-TESTCOB(STEP)-d field-a in hex
> >>>PACKED-STUFF.FIELD-A =3D 0 0 0 1 %H23 %H45 %H60 %HC
>
> >>>-TESTCOB-d field-b in hex
> >>>PACKED-STUFF.FIELD-B =3D %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 %H33 =
%H34
> %H35
> >>>%H36 %H30 %H30 %H30
> >>>-TESTCOB-d field-b in a
> >>>PACKED-STUFF.FIELD-B =3D "000000123456000"
>
> >>>-TESTCOB-d field-c in hex
> >>>PACKED-STUFF.FIELD-C =3D 0 0 %HBC %H6100
>
> >>>-----------------------
> >>>After Move
>
> >>>-TESTCOB(STEP)-d field-a in hex
> >>>PACKED-STUFF.FIELD-A =3D 0 0 0 1 %H23 %H45 %H60 %HC
> >>>-TESTCOB-d field-b in hex
> >>>PACKED-STUFF.FIELD-B =3D %H30 %H30 %H30 %H30 %H30 %H30 %H30 %H31 %H32 =
%H33
> %H34
> >>>%H35 %H36 %H30 %H30
> >>>-TESTCOB-d field-b in a
> >>>PACKED-STUFF.FIELD-B =3D "000000012345600"
> >>>-TESTCOB-d field-c in hex
> >>>PACKED-STUFF.FIELD-C =3D 0 0 %HBC %H6100
>
> >>>----------------
>
> >>>TNS mode ADD zero
> >>>0000000123.45600 =A0 // COMP-3
> >>>0000001234.56000 =A0 // no usage option
> >>>0000000123.45600 =A0 // COMP
>
> >>>TNS mode move
> >>>0000000123.45600 =A0 // COMP-3
> >>>0000000123.45600 =A0 // Move to no usage option
> >>>0000000123.45600 =A0 // move to comp
>
> >> COMPUTE works where ADD fails.
> >> MULTIPLY by 1 works.
>
> >> =A0 =A0 move 123.456 to field-a.
> >> =A0 =A0 display field-a " =A0 // comp-3 value =A0 ".
> >> =A0 =A0 ADD FIELD-A TO ZERO GIVING FIELD-B ROUNDED.
> >> =A0 =A0 display field-b " =A0 // add zero =A0 =A0 =A0 ".
>
> >> =A0 =A0 ADD FIELD-A TO 0.0000 =A0GIVING FIELD-B ROUNDED.
> >> =A0 =A0 display field-b " =A0 // add 0.0000 =A0 =A0 ".
>
> >> =A0 =A0 ADD FIELD-A TO 1 =A0GIVING FIELD-B ROUNDED.
> >> =A0 =A0 display field-b " =A0 // add 1 =A0 =A0 =A0 =A0 =A0".
>
> >> =A0 =A0 multiply FIELD-A by 1 =A0GIVING FIELD-B ROUNDED.
> >> =A0 =A0 display field-b " =A0 // multiply by 1 =A0 =A0 =A0".
>
> >> =A0 =A0 compute field-b =3D field-a + 0
> >> =A0 =A0 display field-b " =A0 // compute field-b =3D field-a + 0 ".
>
> >> =A0 =A0 compute field-b =3D field-a + 1
> >> =A0 =A0 display field-b " =A0 // compute field-b =3D field-a + 1 ".
> >> =A0 =A0 stop run.
>
> >> 0000000123.45600 =A0 // comp-3 value
> >> 0000001234.56000 =A0 // add zero
> >> 0000001234.56000 =A0 // add 0.0000
> >> 0000001244.56000 =A0 // add 1
> >> 0000000123.45600 =A0 // multiply by 1
> >> 0000000123.45600 =A0 // compute field-b =3D field-a + 0
>
> ...
>
> read more =BB

In article <232bb346-31d1-46fd-8273-1ee22c79685f@r24g2000yqd.googlegroups.com>, ChinmaYT <chinmay13@gmail.com> wrote:
>I have one another doubt regarding COMP-3 field.
>
>I am reading a file data in COMP-3 field.
>
>If the file is in EBCDIC, i am getting correct value in COMP-3 field
>and if it is in ASCII, the wrong value gets moved.
>
>Why is it so, does COMP-3 stores in EBCDIC?

No, COMP-3 is not stored in EBCDIC. It's stored in binary, and therefore 
will produce incorrect results if subjected to an EBCDIC-to-ASCII conversion.

Conversions between EBCDIC and ASCII, in either direction, produce valid 
results ONLY on fields that are defined either explicitly or implicitly 
as USAGE DISPLAY. Such conversions on fields with *any* other usage are nearly 
guaranteed to produce incorrect results.

Have a look at the code tables for the two systems here:
http://www.3480-3590-data-conversion.com/article-ebcdic-ascii-table.html

Now consider a field defined as PIC 9(5) COMP-3 VALUE +27224.

The internal representation of this -- on either an EBCDIC or ASCII machine -- 
is three bytes, with these hex values: 27 22 4C.

Now 27 happens to be the EBCDIC code for ESCape, 22 is the EBCDIC code for FS 
(Field Separator), and 4C is the EBCDIC code for < (less-than). Bear in mind 
that the program performing the EBCDIC-to-ASCII conversion has *no way* of 
knowing whether the byte sequence 27 22 4C means packed-decimal +27224, or the 
character string ESC FS <, and thus when this is converted to ASCII, it gets 
converted to the ASCII codes for ESC, FS, and <, resulting in hex values 1B 1C 
3C, which isn't a valid COMP-3 value.

Note that *exactly* the same thing happens with a field defined as PIC 9(9) 
COMP VALUE 2564684 -- this is a binary field, stored internally as hex 00 27 
22 4C, and if converted to ASCII the result will be 00 1B 1C 3C, which will be 
interpreted as decimal 1776700.

In other words, there's nothing special about COMP-3. You don't have a problem 
because the field *is* USAGE COMP-3, you have a problem because the field is 
*not* USAGE DISPLAY.

Doug Miller wrote:
> In article <232bb346-31d1-46fd-8273-1ee22c79685f@r24g2000yqd.googlegroups.com>, ChinmaYT <chinmay13@gmail.com> wrote:
> 
>>I have one another doubt regarding COMP-3 field.
>>
>>I am reading a file data in COMP-3 field.
>>
>>If the file is in EBCDIC, i am getting correct value in COMP-3 field
>>and if it is in ASCII, the wrong value gets moved.
>>
>>Why is it so, does COMP-3 stores in EBCDIC?
> 
> 
> No, COMP-3 is not stored in EBCDIC. It's stored in binary, and therefore 
> will produce incorrect results if subjected to an EBCDIC-to-ASCII conversion.
> 
> Conversions between EBCDIC and ASCII, in either direction, produce valid 
> results ONLY on fields that are defined either explicitly or implicitly 
> as USAGE DISPLAY. Such conversions on fields with *any* other usage are nearly 
> guaranteed to produce incorrect results.
> 
> Have a look at the code tables for the two systems here:
> http://www.3480-3590-data-conversion.com/article-ebcdic-ascii-table.html
> 
> Now consider a field defined as PIC 9(5) COMP-3 VALUE +27224.
> 
> The internal representation of this -- on either an EBCDIC or ASCII machine -- 
> is three bytes, with these hex values: 27 22 4C.
> 
> Now 27 happens to be the EBCDIC code for ESCape, 22 is the EBCDIC code for FS 
> (Field Separator), and 4C is the EBCDIC code for < (less-than). Bear in mind 
> that the program performing the EBCDIC-to-ASCII conversion has *no way* of 
> knowing whether the byte sequence 27 22 4C means packed-decimal +27224, or the 
> character string ESC FS <, and thus when this is converted to ASCII, it gets 
> converted to the ASCII codes for ESC, FS, and <, resulting in hex values 1B 1C 
> 3C, which isn't a valid COMP-3 value.
> 
> Note that *exactly* the same thing happens with a field defined as PIC 9(9) 
> COMP VALUE 2564684 -- this is a binary field, stored internally as hex 00 27 
> 22 4C, and if converted to ASCII the result will be 00 1B 1C 3C, which will be 
> interpreted as decimal 1776700.
> 
> In other words, there's nothing special about COMP-3. You don't have a problem 
> because the field *is* USAGE COMP-3, you have a problem because the field is 
> *not* USAGE DISPLAY.
> 

This is exactly the correct explanation if the ASCII file was created by performing an EBCDIC-to-ASCII conversion on the whole file.  (Some conversion programs permit the user to describe the record layout and which fields to convert and which fields to leave unchanged.)

I imagine the file was created on an IBM system (or an IBM-compatible system).  I do not know whether it is possible to make programs on an IBM system work natively in ASCII, but if it is possible to do that, and if the file you are trying to use was created natively in ASCII, then I imagine the problem with the COMP-3 field is caused by something different than what Doug explains.

I imagine that it is very likely that the file did go through an EBCDIC-to-ASCII conversion at some point, so I imagine Doug's description is what happened, so I will not speculate further on other explanations at this point.  But if no EBCDIC-to-ASCII conversion was done on your file, then explain more about how it was created and processed, and we may be able to help you find out what the problem is. 

Yes, the file is created in IBM system. I am reading the packed data
from it and storing on Tandem files.

At last i did something like this
Convert input data file in EBCDIC using fup info FILEASC, FILEEBC,
ebcdicout
Used FILEEBC in my program.
Used ADD FILED-A TO ZERO GIVING FIELD-B for packed data.
and converted not packed fields using EBCDICtoASCII (my library)

Thus i got the correct data now and able to process it on Tandem.

On Jan 6, 10:52=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
> Doug Miller wrote:
> > In article <232bb346-31d1-46fd-8273-1ee22c796...@r24g2000yqd.googlegrou=
ps.com>, ChinmaYT <chinma...@gmail.com> wrote:
>
> >>I have one another doubt regarding COMP-3 field.
>
> >>I am reading a file data in COMP-3 field.
>
> >>If the file is in EBCDIC, i am getting correct value in COMP-3 field
> >>and if it is in ASCII, the wrong value gets moved.
>
> >>Why is it so, does COMP-3 stores in EBCDIC?
>
> > No, COMP-3 is not stored in EBCDIC. It's stored in binary, and therefor=
e
> > will produce incorrect results if subjected to an EBCDIC-to-ASCII conve=
rsion.
>
> > Conversions between EBCDIC and ASCII, in either direction, produce vali=
d
> > results ONLY on fields that are defined either explicitly or implicitly
> > as USAGE DISPLAY. Such conversions on fields with *any* other usage are=
 nearly
> > guaranteed to produce incorrect results.
>
> > Have a look at the code tables for the two systems here:
> >http://www.3480-3590-data-conversion.com/article-ebcdic-ascii-table.html
>
> > Now consider a field defined as PIC 9(5) COMP-3 VALUE +27224.
>
> > The internal representation of this -- on either an EBCDIC or ASCII mac=
hine --
> > is three bytes, with these hex values: 27 22 4C.
>
> > Now 27 happens to be the EBCDIC code for ESCape, 22 is the EBCDIC code =
for FS
> > (Field Separator), and 4C is the EBCDIC code for < (less-than). Bear in=
 mind
> > that the program performing the EBCDIC-to-ASCII conversion has *no way*=
 of
> > knowing whether the byte sequence 27 22 4C means packed-decimal +27224,=
 or the
> > character string ESC FS <, and thus when this is converted to ASCII, it=
 gets
> > converted to the ASCII codes for ESC, FS, and <, resulting in hex value=
s 1B 1C
> > 3C, which isn't a valid COMP-3 value.
>
> > Note that *exactly* the same thing happens with a field defined as PIC =
9(9)
> > COMP VALUE 2564684 -- this is a binary field, stored internally as hex =
00 27
> > 22 4C, and if converted to ASCII the result will be 00 1B 1C 3C, which =
will be
> > interpreted as decimal 1776700.
>
> > In other words, there's nothing special about COMP-3. You don't have a =
problem
> > because the field *is* USAGE COMP-3, you have a problem because the fie=
ld is
> > *not* USAGE DISPLAY.
>
> This is exactly the correct explanation if the ASCII file was created by =
performing an EBCDIC-to-ASCII conversion on the whole file. =A0(Some conver=
sion programs permit the user to describe the record layout and which field=
s to convert and which fields to leave unchanged.)
>
> I imagine the file was created on an IBM system (or an IBM-compatible sys=
tem). =A0I do not know whether it is possible to make programs on an IBM sy=
stem work natively in ASCII, but if it is possible to do that, and if the f=
ile you are trying to use was created natively in ASCII, then I imagine the=
 problem with the COMP-3 field is caused by something different than what D=
oug explains.
>
> I imagine that it is very likely that the file did go through an EBCDIC-t=
o-ASCII conversion at some point, so I imagine Doug's description is what h=
appened, so I will not speculate further on other explanations at this poin=
t. =A0But if no EBCDIC-to-ASCII conversion was done on your file, then expl=
ain more about how it was created and processed, and we may be able to help=
 you find out what the problem is.

It would be MUCH better if you could get the original EBCDIC file.

The problem is that it is quite possible that a conversion from EBCDIC to ASCII, then back to EBCDIC, will not give exactly the same data in the resulting file as was in the original file.  The character fields might look okay, but the packed decimal fields (and any binary fields) very well might not be okay.

EBCDIC to ASCII is not a one-to-one mapping.  EBCDIC is an 8-bit code while ASCII is a 7-bit code, so a given ASCII character could be the translation of more than one EBCDIC character in the first conversion, so the second conversion is ambiguous -- it cannot know for sure which of the several possible EBCDIC characters that ASCII character should convert to.  It is true that not all possible 256 character codes are valid EBCDIC characters, but more than 128 of them are defined, and that is more than fit into the 128 ASCII codes that are available, so the reverse conversion must be ambiguous.  

Another way to think about it is this: Many of the possible values of a byte that contains two packed decimal digits are not defined to be valid EBCDIC characters.  Just looking at the EBCDIC table quickly shows that: x50 through x59 are undefined, x62 through x69 are undefined, and many more.  So how those bytes get converted when converting to ASCII is undefined.  It is hard for me to believe that after converting such a byte to ASCII then back to EBCDIC, it would have the same value as it started with.

It might appear that you have solved your problem by converting the ASCII file back to EBCDIC, but if I were you, I would not be very confident that all of the packed decimal fields now have the correct values.

Perhaps there is some factor I'm not thinking of that makes what you did safer than I think it is.  If so, I'd be happy to be enlightened about it.

Do yourself a favor and get whoever is supplying you with that data file to give you the original EBCDIC file.  Then there will be no question whether you have the correct values.

ChinmaYT wrote:
> Yes, the file is created in IBM system. I am reading the packed data
> from it and storing on Tandem files.
> 
> At last i did something like this
> Convert input data file in EBCDIC using fup info FILEASC, FILEEBC,
> ebcdicout
> Used FILEEBC in my program.
> Used ADD FILED-A TO ZERO GIVING FIELD-B for packed data.
> and converted not packed fields using EBCDICtoASCII (my library)
> 
> Thus i got the correct data now and able to process it on Tandem.
> 
> On Jan 6, 10:52 pm, Keith Dick <KeithD...@earthlink.net> wrote:
> 
>>Doug Miller wrote:
>>
>>>In article <232bb346-31d1-46fd-8273-1ee22c796...@r24g2000yqd.googlegroups.com>, ChinmaYT <chinma...@gmail.com> wrote:
>>
>>>>I have one another doubt regarding COMP-3 field.
>>
>>>>I am reading a file data in COMP-3 field.
>>
>>>>If the file is in EBCDIC, i am getting correct value in COMP-3 field
>>>>and if it is in ASCII, the wrong value gets moved.
>>
>>>>Why is it so, does COMP-3 stores in EBCDIC?
>>
>>>No, COMP-3 is not stored in EBCDIC. It's stored in binary, and therefore
>>>will produce incorrect results if subjected to an EBCDIC-to-ASCII conversion.
>>
>>>Conversions between EBCDIC and ASCII, in either direction, produce valid
>>>results ONLY on fields that are defined either explicitly or implicitly
>>>as USAGE DISPLAY. Such conversions on fields with *any* other usage are nearly
>>>guaranteed to produce incorrect results.
>>
>>>Have a look at the code tables for the two systems here:
>>>http://www.3480-3590-data-conversion.com/article-ebcdic-ascii-table.html
>>
>>>Now consider a field defined as PIC 9(5) COMP-3 VALUE +27224.
>>
>>>The internal representation of this -- on either an EBCDIC or ASCII machine --
>>>is three bytes, with these hex values: 27 22 4C.
>>
>>>Now 27 happens to be the EBCDIC code for ESCape, 22 is the EBCDIC code for FS
>>>(Field Separator), and 4C is the EBCDIC code for < (less-than). Bear in mind
>>>that the program performing the EBCDIC-to-ASCII conversion has *no way* of
>>>knowing whether the byte sequence 27 22 4C means packed-decimal +27224, or the
>>>character string ESC FS <, and thus when this is converted to ASCII, it gets
>>>converted to the ASCII codes for ESC, FS, and <, resulting in hex values 1B 1C
>>>3C, which isn't a valid COMP-3 value.
>>
>>>Note that *exactly* the same thing happens with a field defined as PIC 9(9)
>>>COMP VALUE 2564684 -- this is a binary field, stored internally as hex 00 27
>>>22 4C, and if converted to ASCII the result will be 00 1B 1C 3C, which will be
>>>interpreted as decimal 1776700.
>>
>>>In other words, there's nothing special about COMP-3. You don't have a problem
>>>because the field *is* USAGE COMP-3, you have a problem because the field is
>>>*not* USAGE DISPLAY.
>>
>>This is exactly the correct explanation if the ASCII file was created by performing an EBCDIC-to-ASCII conversion on the whole file.  (Some conversion programs permit the user to describe the record layout and which fields to convert and which fields to leave unchanged.)
>>
>>I imagine the file was created on an IBM system (or an IBM-compatible system).  I do not know whether it is possible to make programs on an IBM system work natively in ASCII, but if it is possible to do that, and if the file you are trying to use was created natively in ASCII, then I imagine the problem with the COMP-3 field is caused by something different than what Doug explains.
>>
>>I imagine that it is very likely that the file did go through an EBCDIC-to-ASCII conversion at some point, so I imagine Doug's description is what happened, so I will not speculate further on other explanations at this point.  But if no EBCDIC-to-ASCII conversion was done on your file, then explain more about how it was created and processed, and we may be able to help you find out what the problem is.
> 
>