View previous topic :: View next topic
|
Author |
Message |
abin
Active User
Joined: 14 Aug 2006 Posts: 198
|
|
|
|
Hi,
I have a file in which I have couple of numeric edited variables. I need to reformat the file into an output where all edited numeric is converted into COMP-3 or zone-decimal. In the i/p file I get there is possibility of having improper value. For example a +96).9 field coming with leading sign missing or with space populated. Is there any intrinsic way in COBOL to check the validity of edited numeric fields. I tried IS NUMERIC in IF clause. but it is working only when the edited numeric does note have a decimal point.
Thanks,
Abin. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
To be completely protected from an abend suggest you parse the "input field" one byte at a time (from the right side or "reversed") and build a new valid work field that would contain all of the significant digits, a decimal point if applicable, and a trailing sign. Once this validated field has been build, use NUMVAL (or NUMVAL-C) to move the "good" value to the comp-3 field.
If the value is not valid NUMVAL will abend rather ungracefully, so you need to ensure valid data.
You would need only 1 routine unless the "rules" are different somehow. |
|
Back to top |
|
|
abin
Active User
Joined: 14 Aug 2006 Posts: 198
|
|
|
|
Hi Dick,
Thanks for the suggestion.
Looks like I will have to change the input file format to DISPLAY without decimal point. In I/P file creation process I will have to multiply all decimal dgits with 10 to the pwers to remove the decimal.
If I try to go with NUMVAL I will end up creating multiple routine(there are different numeric PIC clause in my I/P file like +9(7).99, +.99, +9(7) etc). And I cannot ensure a vlid data always. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
abin wrote: |
Looks like I will have to change the input file format to DISPLAY without decimal point. In I/P file creation process I will have to multiply all decimal dgits with 10 to the pwers to remove the decimal. |
No you don't and why do you think you need to?
Quote: |
If I try to go with NUMVAL I will end up creating multiple routine(there are different numeric PIC clause in my I/P file like +9(7).99, +.99, +9(7) etc). And I cannot ensure a vlid data always. |
No again, it is a simple move from the edited field to a zoned or packed decimal field.
Have you looked at NUMVAL or NUMVAL-C?
If the input data is that corrupted, a general purpose scan and move can clean up the input so that the NUMVALs will not error..... |
|
Back to top |
|
|
abin
Active User
Joined: 14 Aug 2006 Posts: 198
|
|
|
|
Ok, I will try out this methord. Will update you on the result. Thanks again. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
In the i/p file I get there is possibility of having improper value |
It all depends on this. . .
If a program creates the edited field(s) there should be no such possibility.
Quote: |
For example a +96).9 field coming with leading sign missing or with space populated. |
How could this be created by "editing" some numeric value? |
|
Back to top |
|
|
abin
Active User
Joined: 14 Aug 2006 Posts: 198
|
|
|
|
Hi Dick,
The input file is not created using a COBOL code but using Informatica technology in Unix environment. That is the reason why the edited fields might have improper values.
Thanks,
Abin. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Informatica properly "edits" numeric values. . . What could be specified in an Informatica process that would cause this output (For example a +96).9 field)?
What kind of user would want such output?
Obviously, there is something i misunderstand. . . |
|
Back to top |
|
|
|