IBM Mainframe Forum

Hi Seniors,

I have an issue in moving a decimal field from an edited field to COMP-3 table field.
Say I have value '256.52' read as text from input file, the variable declared as PIC X(18)
After a zero insertion logic to make it an edited numeric field with PIC clause PIC 9(15).9(2), I get it as 000000000000256.52
But when I move it to the table field, defined in DCLGEN with PIC clause PIC S9(16)V9(2) USAGE COMP-3, I get it as 0000000000025652.00.

Can someone help me out?

Thanks,
AS

See the various posts along these lines in the forum.

But when I move it to the table field

What is "it" in this context -- the PIC X(18) variable or the PIC 9(15).9(2) variable? If "it" refers to the PIC X(18) variable, then you are getting the results you asked for because the implied decimal point for ANY PIC X variable is immediately to the right of the last character. Use FUNCTION NUMVAL or something other than PIC X(18) as the sending variable.

Sorry, here "it" is not PIC X(18), but edited field. PIC 9(15).9(2) --> PIC S9(16)V9(2) USAGE COMP-3 is giving me 000000000000256.52 --> 0000000000025652.00

Sorry, here "it" is not PIC X(18), but edited field. PIC 9(15).9(2) --> PIC S9(16)V9(2) USAGE COMP-3 is giving me 000000000000256.52 --> 0000000000025652.00

OK, you're lying somewhere. If you have a PIC S9(16)V9(2) COMP-3 variable and you move 256.52 to it, you will get '000000000000025652' (ignoring the sign for a moment) as the value since a V in a PICTURE clause is an IMPLIED decimal point and not an actual decimal point -- it NEVER shows up anywhere. So your results do not match what you say the PICTURE is. Furthermore, I ran this code and I got output of I'm not quite sure what happened to the sign (I was expecting the last five characters to be '2565B' not '25652') but the results I got may be due to using an unsigned source variable. The results clearly demonstrate that there will be no decimal point in the output (target) variable. If you are expecting to see output of 256.52, you are not going to see that -- ever -- as long as there is a V in the PICTURE clause.

Thanks for executing it. Actually the problem is not that output doesn't have a decimal. But the resulting value is getting multiplied with 100. If I say wrt your above example, what I get is not 000000000000025652 but 000000000002565200. Even in the table, it's getting updated as 25652.00, where as expected is 256.52.

Thanks for understanding and taking time to give your suggestion.

One of two things is happening:
1. The variable is being multiplied by 100 somewhere.
2. There is an alignment issue somewhere -- since COBOL aligns numeric fields to the decimal point, if there is code that moves an alphanumeric variable to the variable, the alignment rules would change the value.

Without more information, we cannot further help you. As I showed in my code, COBOL handles the data correctly. Why yours is not working is due to something IN YOUR CODE, and without posting the code we have nothing to be able to help you with.

Thanks for your time.
But I have checked the same in DEBUG session and found that the decimal issue is happening exactly at the place of move. that is, as I have detailed above
when the variable declared as PIC 9(15).9(2) is MOVE ing its value (000000000000256.52) to the Table DCLGEN field declared as PIC S9(16)V9(2) USAGE COMP-3, the value gets changed as 0000000000025652.00.

So as suspected above, it's not the case of getting multiplied with 100. Also I don't know if an alignment change occurs at this MOVE statement. Kindly Suggest.

I suspect the alignment issue is occurring in the move TO the PIC 9(16).9(2) variable and not to the COMP-3 variable. Furthermore, as I've said multiple times, 0000000000025652.00 is not a valid PIC 9(16)V9(2) COMP-3 value.

You are stating that something is happening that simply CANNOT happen. Topic locked to prevent further wasting of our time -- you're not posting actual code, you insist you're getting impossible results, and you seem to think the problem is with the system and not with your code (hint: the problem lies in your code somewhere).