Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref

Author Message
Priyanka Pyne

New User

Joined: 09 Feb 2008
Posts: 95
Location: India

 Posted: Tue Jan 24, 2012 1:32 am    Post subject: Moving data from 9(5) to 99,999.99 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.

Bill Woodger

DFSORT Moderator

Joined: 09 Mar 2011
Posts: 7314

Posted: Tue Jan 24, 2012 1:43 am    Post subject: Re: Moving data from 9(5) to 99,999.99

 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.
Robert Sample

Global Moderator

Joined: 06 Jun 2008
Posts: 8231
Location: Dubuque, Iowa, USA

 Posted: Tue Jan 24, 2012 1:51 am    Post subject: 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.
Priyanka Pyne

New User

Joined: 09 Feb 2008
Posts: 95
Location: India

Posted: Tue Jan 24, 2012 2:13 am    Post subject:

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.
Bill Woodger

DFSORT Moderator

Joined: 09 Mar 2011
Posts: 7314

Posted: Tue Jan 24, 2012 3:37 am    Post subject:

 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.
Priyanka Pyne

New User

Joined: 09 Feb 2008
Posts: 95
Location: India

 Posted: Tue Jan 24, 2012 3:53 am    Post subject: Thanks Bill But still I didnt get hoe to resolve this
Bill Woodger

DFSORT Moderator

Joined: 09 Mar 2011
Posts: 7314

 Posted: Tue Jan 24, 2012 5:05 am    Post subject: Reply to: Moving data from 9(5) to 99,999.99 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.
Bill O'Boyle

CICS Moderator

Joined: 14 Jan 2008
Posts: 2504
Location: Atlanta, Georgia, USA

 Posted: Tue Jan 24, 2012 6:36 am    Post subject: Reply to: Moving data from 9(5) to 99,999.99 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
 All times are GMT + 6 Hours
 Page 1 of 1

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics Get the list of data sets on DASD and... rakaitn JCL & VSAM 3 Thu Mar 08, 2018 12:38 pm Data security erase on RAID device steve-myers All Other Mainframe Topics 0 Sat Jan 13, 2018 6:41 am Append the milliseconds to the data s... girishb2 DFSORT/ICETOOL 1 Thu Dec 21, 2017 9:07 pm Moving a COMP-3 Variable to a Numeric... ajayachander COBOL Programming 2 Thu Dec 14, 2017 5:46 pm Extract record for change in combinat... Trinadh DFSORT/ICETOOL 6 Thu Nov 23, 2017 3:32 pm

 © 2003-2017 IBM MAINFRAME Software Support Division
 Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us