Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Edited Numeric variable validity check

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
abin

Active User


Joined: 14 Aug 2006
Posts: 198

PostPosted: Thu Apr 15, 2010 3:24 am    Post subject: Edited Numeric variable validity check
Reply with quote

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
View user's profile Send private message

dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Apr 15, 2010 3:58 am    Post subject:
Reply with quote

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
View user's profile Send private message
abin

Active User


Joined: 14 Aug 2006
Posts: 198

PostPosted: Thu Apr 15, 2010 4:25 am    Post subject:
Reply with quote

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
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

PostPosted: Thu Apr 15, 2010 4:57 am    Post subject:
Reply with quote

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
View user's profile Send private message
abin

Active User


Joined: 14 Aug 2006
Posts: 198

PostPosted: Thu Apr 15, 2010 5:08 am    Post subject:
Reply with quote

Ok, I will try out this methord. Will update you on the result. Thanks again.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Apr 15, 2010 6:48 am    Post subject:
Reply with quote

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
View user's profile Send private message
abin

Active User


Joined: 14 Aug 2006
Posts: 198

PostPosted: Thu Apr 15, 2010 10:18 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Apr 16, 2010 12:07 am    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Validate if a Value from the file is ... balacsv2 COBOL Programming 8 Mon Jun 19, 2017 11:52 pm
No new posts Can I traverse a STEM variable? chong.zhou CLIST & REXX 5 Wed May 31, 2017 3:54 pm
No new posts Converting Variable block file to Fix... bhavana yalavarthi DFSORT/ICETOOL 10 Tue May 16, 2017 2:20 pm
No new posts Validate date and numeric fields and ... Rick Silvers DFSORT/ICETOOL 6 Thu May 11, 2017 6:51 pm
No new posts Check if any Detail records and extra... V S Amarendra Reddy SYNCSORT 19 Mon May 08, 2017 8:54 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us