|
View previous topic :: View next topic
|
| Author |
Message |
Priyanka Pyne
New User
Joined: 09 Feb 2008
Posts: 95
Location: India
|
|
|
|
Hi,
Field 1 describe as 9(5)
Field 2 describe as 99,999.99
Field 1 value is 350.0
When I am moving the data from field1 to field2, the value is getting changed as 35,0.0.00. But the expected value is 350.00
What could be the correct declaration in this case. |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Priyanka Pyne wrote: |
Hi,
Field 1 describe as 9(5)
Field 2 describe as 99,999.99
Field 1 value is 350.0
When I am moving the data from field1 to field2, the value is getting changed as 35,0.0.00. But the expected value is 350.00
What could be the correct declaration in this case. |
PIC X(5). Or PIC ZZZ9.9. Depends if you have leading or trailing spaces and if the number of decimals is fixed. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
Your program is doing exactly what you told it to do in this case. A PIC 9(5) variable with a value of 350.0 has a big problem. With no decimal point in the PICTURE clause, there should be no decimal piont in the value. When there is, expect the decimal point to be treated as a digit and not a decimal point.
COBOL aligns the decimal points -- the implied decimal point in field 1 is just to the right of the last digit (since it has no decimal place defined in the PICTURE clause). The two digits after the decimal are set to zero in field 2, then the 5 characters of field 1 are moved, using the PICTURE clause, to field 2:
zero to the character just before the decimal point
period to the character to the left of the previous one
zero to the character to the left of the previous one
the comma is left alone
the five is moved to the character before the comma
the three is moved to the left of the previous character
Hence you told the system to generate 35,0.0.00 and it did. |
|
| Back to top |
|
|
Priyanka Pyne
New User
Joined: 09 Feb 2008
Posts: 95
Location: India
|
|
|
|
Yes Robert. I completely agree with you. My program is an existing production code. And the value is coming from a .txt file. Hence it is reading in a char field. The processing as as follows:
| Code: |
MOVE WS-UNITS TO WS-SPLIT-UNITS
IF WS-UNITS-5 NUMERIC
MOVE WS-UNITS TO WS-NUM-UNITS-5
MOVE WS-NUM-UNITS-5-B TO WS-MONTHLY-BEN
MOVE WS-MONTHLY-BEN TO WS-MONTHLY-BEN-2
MOVE WS-MONTHLY-BEN-2 TO WS-MO-BEN-OUT-BASE
END-IF
|
Now the declaration of the fields are as below:
05 WS-UNITS PIC X(09) VALUE SPACES.
05 WS-SPLIT-UNITS.
10 WS-UNITS-1 PIC X(01).
10 WS-UNITS-2 PIC X(01).
10 WS-UNITS-3 PIC X(01).
10 WS-UNITS-4 PIC X(01).
10 WS-UNITS-5 PIC X(01).
10 FILLER PIC X(04).
05 WS-NUM-UNITS-5 PIC X(05).
05 WS-NUM-UNITS-5-B REDEFINES WS-NUM-UNITS-5 PIC 9(05)
05 WS-MONTHLY-BEN PIC 9(05).
05 WS-MONTHLY-BEN-2 PIC 99,999.99. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Code: |
MOVE WS-UNITS TO WS-SPLIT-UNITS
05 WS-UNITS PIC X(09) VALUE SPACES.
05 WS-SPLIT-UNITS.
10 WS-UNITS-1 PIC X(01).
10 WS-UNITS-2 PIC X(01).
10 WS-UNITS-3 PIC X(01).
10 WS-UNITS-4 PIC X(01).
10 WS-UNITS-5 PIC X(01).
10 FILLER PIC X(04).
IF WS-UNITS-5 NUMERIC
05 WS-NUM-UNITS-5 PIC X(05).
05 WS-NUM-UNITS-5-B REDEFINES WS-NUM-UNITS-5 PIC 9(05)
05 WS-MONTHLY-BEN PIC 9(05).
05 WS-MONTHLY-BEN-2 PIC 99,999.99.
MOVE WS-UNITS TO WS-NUM-UNITS-5
MOVE WS-NUM-UNITS-5-B TO WS-MONTHLY-BEN
MOVE WS-MONTHLY-BEN TO WS-MONTHLY-BEN-2
MOVE WS-MONTHLY-BEN-2 TO WS-MO-BEN-OUT-BASE
END-IF
|
I've moved the field definitions to "embed" them were they are used (or not).
Since the code is doing nothing with WS-SPLIT-UNITS or its subordinate items, ignore that.
Then the code tests WS-UNITS-5 for begin numeric which is from the previous time through this piece of code.
Then the items are shuffled around a bit into your edited field, "by accident" setting WS-UNITS-5 for the next time the code is used, for the next data, yet this that nex time it will not be "NUMERIC" as it will contain the actual decimal place.
I hope it is just a report, and I hope the code has not been like that for long. How many people missed that for it to get into Production? Make sure your boss lets the testing boss(es) know about this. |
|
| Back to top |
|
|
Priyanka Pyne
New User
Joined: 09 Feb 2008
Posts: 95
Location: India
|
|
|
|
Thanks Bill
But still I didnt get hoe to resolve this  |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
What is the format of your incoming field? I'm guessing it has a "numeric edited" format in that it contains an actual decimal place.
Does it have leading, or trailing, blanks?
Does it have a fixed (one) or variable number of decimal places (none, one or two)?
If might be possible to use intrinsic function NUMVAL, but the NUMERIC test (without knowledge of the data) is worrying. Is there a possibility of genuine non-numerics, or is that someone's weird idea of how to find an actual decimal place? If you give NUMVAL an invalid numeric edited value it will abend.
If it is a simple format, with a possible decimal point but no other editing, you can use UNSTRING, You can define/redefine definitions with an appropriate number of places. You can do byte-by-byte moves. You can do "de-editing". But you have to know the data format. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Why not manually right-justify it into a much larger 18-Byte Display-Numeric field (initialized to zeros, which will give you wiggle room), removing all non-numeric bytes beforehand?
You can then play with the data any way you'd like.
An in-line PERFORM would do the trick....
Mr. Bill |
|
| Back to top |
|
|
|
|
