|
View previous topic :: View next topic
|
| Author |
Message |
Nsuma
New User
Joined: 10 Dec 2007
Posts: 13
Location: Hyd
|
|
|
|
HI ALL,
In my application I have one rate-filed,
From the file some times I am getting value as some 19.24
But when I validate the rate-filed with is numeric clause it is giving not numeric result, but this rate is valid for my application, how to take this rate-filed is valid at this rate (19.24) in this situation.
Pic clause of rate-field is s9(10)v99. |
|
| Back to top |
|
 |
Gnanas N
Active Member
Joined: 06 Sep 2007
Posts: 792
Location: Chennai, India
|
|
|
|
Nsuma,
Since PIC clause of rate-field is S9(10)V99, the value in the file should be 000000001924. V indicates that it's assumed decimal point.
Do correct me if I don't understand your problem. |
|
| Back to top |
|
|
Nsuma
New User
Joined: 10 Dec 2007
Posts: 13
Location: Hyd
|
|
|
|
HI gnanas,
Some times i am getting rate value from the client 19.24 instead of 1924.but these two values are valid for me as per requirement,but when i am checking 19.24 is numeric,it is giving not numeric result,but how can make the 19.24 as valid numeric...is there any possilblity to validate as numeric ...please let me know |
|
| Back to top |
|
|
Gnanas N
Active Member
Joined: 06 Sep 2007
Posts: 792
Location: Chennai, India
|
|
|
|
Nsuma,
| Quote: |
| Some times i am getting rate value from the client 19.24 instead of 1924. |
Are you getting the value from file?
Is it okay to give two type of values(19.24 or 1924) for the same field?
Doesn't it make problem while reading the file?
Do correct me if I am wrong. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
It looks like there is a lot of confusion about data conversion,validation...
every shop should have standards and STRONG suggestions on how to deal
with fields which are not program generated...
let' s suppose that the data comes thru a field in a cics map..
1) the field is defined as a generic field ( NO num, justify, fill subparameters )
then it is the application responsibility to validate each char as acceptable,
and convert the field to the to the desired format...
( a field can be entered in free format )
2 the field is defined as NUMERIC, ZERO FILLED, RIGHT JUSTIFIED
( look at the cics manual for the assumptions and mix )
then after a receive map, You will be certain that the field is numeric,
the only drawback of this approach is that the end user will have always to enter
the digits implied after the decimal comma/point
( but without physically entering the decimal separator )
I alway wonder why so many posters ask abut this issue...
ALL the shops were I worked had, or I forced them to have,
a STANDARD numeric validation and conversion routine
with different degrees of sophystication, but still a standard one,
with even a default message standardized across the applications
simple effective, no need to reinvent the wheel each time |
|
| Back to top |
|
|
|
|
