I use FUNCTION NUMVAL(fieldname) to convert an alpha field to a numeric value.
That works fine as long as the field contains numbers, decinal point and possibly a minus sign. It DOES NOT work if the field has a comma.
Good example: 1234.55
Bad example: 1,234.55
Is there another function that will convert the field if it contains a comma?
Function to Convert Numeric Data
Moderators: dbzTHEdinosauer, Moderator Group
Function to Convert Numeric Data
David Earhart
-
- Active Member
- Posts: 732
- Joined: Thu May 24, 2012 4:07 am
No.
Is the number you want to convert in a fixed position?
I'd just REDFINES so I can get at the parts of the field, check that commas are commas, decimal-point is ",", parts are numeric, and then put the number together with MOVEs to a receiver without the editing characters.
If you can't be bothered with checking for validity, you can REDEFINES with an editing PICture which represents the data and just MOVE it to your numeric destination field (it's called "de-editing").
If the number is not in a fixed position, you can always arrange that it is so, and proceed as above. Ensure there is always at least one leading blank, UNSTRING to two fields DELIMITED BY ALL SPACE, ignore the first field and define the second as alpha-numeric with JUSTIFIED RIGHT.
I never use NUMVAL or NUMVAL-C. As you notice, they die in an instant with "bad" data, and no way to determine beforehand that the data is bad, without writing code which then means you don't need to use them...
Is the number you want to convert in a fixed position?
I'd just REDFINES so I can get at the parts of the field, check that commas are commas, decimal-point is ",", parts are numeric, and then put the number together with MOVEs to a receiver without the editing characters.
If you can't be bothered with checking for validity, you can REDEFINES with an editing PICture which represents the data and just MOVE it to your numeric destination field (it's called "de-editing").
If the number is not in a fixed position, you can always arrange that it is so, and proceed as above. Ensure there is always at least one leading blank, UNSTRING to two fields DELIMITED BY ALL SPACE, ignore the first field and define the second as alpha-numeric with JUSTIFIED RIGHT.
I never use NUMVAL or NUMVAL-C. As you notice, they die in an instant with "bad" data, and no way to determine beforehand that the data is bad, without writing code which then means you don't need to use them...
Try following code.
Code: Select all
01 Sample.
05 WS-SOURCE PIC X(8) VALUE '1,234.55'.
05 WS-SOURCE-R REDEFINES WS-SOURCE
PIC 9,999.99.
01 WS-TARGET-VALUE PIC 9(8).
PROCEDURE DIVISION.
MOVE WS-SOURCE-R TO WS-TARGET-VALUE .
-
- Active Member
- Posts: 732
- Joined: Thu May 24, 2012 4:07 am
-
- Active Member
- Posts: 732
- Joined: Thu May 24, 2012 4:07 am
Yes, I think I must have looked at the syntax diagram for NUMVAL twice
If your data is coming from Excel, why don't you get the output without the commas anyway? Or are you working off an existing output which can't be changed, and you can't get your own?
Excel is good news for NUMVAL/NUMVAL-C, because the data is going to be a valid format - except for that occasion when you get the output field filled (you'll see lots of #s). If the output field from Excel is large enough that that can't happen (guaranteed) then fine. But I'd still check for that value, and do something, rather than just let NUMVAL-C crash.
I'd personally still do it differently. How big are your fields? More than 15 significant digits? Watch for that with NUMVAL/NUMVAL-C. The other thing is that you get "a floating-point approximation" out of NUMVAL/NUMVAL-C, You may want to check what happens with values which can't be exactly expressed as a floating-point value.
If your data is coming from Excel, why don't you get the output without the commas anyway? Or are you working off an existing output which can't be changed, and you can't get your own?
Excel is good news for NUMVAL/NUMVAL-C, because the data is going to be a valid format - except for that occasion when you get the output field filled (you'll see lots of #s). If the output field from Excel is large enough that that can't happen (guaranteed) then fine. But I'd still check for that value, and do something, rather than just let NUMVAL-C crash.
I'd personally still do it differently. How big are your fields? More than 15 significant digits? Watch for that with NUMVAL/NUMVAL-C. The other thing is that you get "a floating-point approximation" out of NUMVAL/NUMVAL-C, You may want to check what happens with values which can't be exactly expressed as a floating-point value.
FREE TUTORIALS
Tutorials
Free tutorials from mainframegurukul
- JCL Tutorial
Covers all important JCL concepts. - Cobol Tutorial
This tutorials covers all Cobol Topics from STRING to COMP-3. - DB2 Tutorial
DB2 Tutorial focuses on DB2 COBOL Programming. - SORT Tutorial
This Tutorial covers all important aspects of DFSORT with examples - CICS Tutorial
This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions
- Cobol Interview Questions
50+ Interview Questions - JCL Interview Questions
50+ Interview Questions - DB2 Interview Questions
100+ Interview Questions - CICS Interview Questions
70+ Interview Questions - VSAM Interview Questions
27 Interview Questions
Other References
Mainframe Tools and others
- XPEDITER Reference
Explains how we can debug a program - FILEAID Reference
Explains how to browse , edit and delete datasets - Change Man Reference
Quick Start tutorial on Changeman - Abend Reference
Important Abend codes explained - FaceBook Page
MainframeGurukul FaceBook Page - LinkedIn Page
MainframeGurkul Linkedin Page