Where 51.500 is the ideal value as I'm expecting to extract the value as PIC9(2)V9(3).
But at the sametime if the value is 51.50 or 51.5 or 51 , then I should convert this to PIC9(2)V9(3) [ or TT.TTT] before converting it to PD!
I tried using MUL by 1000 and then dividing by 1000 to see if it'll work, but failed.
Joined: 26 Jan 2006 Posts: 6 Location: Kuala Lumpur
Bill,
The 13th Field, is a ''floating point'' field, but I just gave an example where I had the trouble, and yes where the trailing zeros are suppressed up to the decimal point.
And I did tried all of that I know, and not assume!!
I can't give the actual output over here as its a production data. But the output was like following,
I/p - O/p
51.500 - 51.500 --- > Correct, as expected
51.50 - 5.150 -----> Incorrect
51.5 - 0.515 -----> Incorrect
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
sl2pradeep wrote:
The 13th Field, is a ''floating point'' field
for your information, 'floating point' has a definite mathematical definition,
you problem does not qualify.
your problem is that your input in not formated consistantly.
and it is 'pre-edited', which means that it is a char field and not a numeric field.
you are causing yourself problems by defining the field as UFF/SFF
from articles and manuals concerning UFF and SFF:
Quote:
Any combination of characters is valid,
but characters other than 0-9, the minus sign, and the rightparenthesis
are ignored.
(emphasis is mine)
the above tells me that the decimal point,
which is not consistantly formated with trailing numerics,
is ignored.
so, the problem is your parsing technique.
my limited DFSORT capabilities would lead me down this path:
1. parse two fields
the first: prior to the 'decimal point' (the period)
the second: after the 'decimal point' (the period)
2. expand the second to a consistant size
3. put them together and do the 'TO PD,LENGTH=3
or wait for Frank or Kolusu to provide a solution.
Joined: 26 Jan 2006 Posts: 6 Location: Kuala Lumpur
Thanks Dick..
Just got a way-around using NUMVAL in COBOL.
The NUMVAL function returns the numeric value represented by the alphanumeric character string specified in an argument. The function strips away any leading or trailing blanks in the string, producing a numeric value that can be used in an arithmetic expression.
but will wait to see if Frank or Kolusu has any solution to this one in DF or SYncSort.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
sl2pradeep wrote:
[...]
The 13th Field, is a ''floating point'' field [...]
Hi, Dick has already provided you with an excellent explanation of what you are doing to achieve your incorrect results.
It may aid your future knowledge if you do a google search for "what is a floating point number".
In a "floating point number", a completely different thing from what you are talking about, the visible decimal place will always be in the same position with an "exponent" (a power in whatever number base) to tell you where the decimal point is for calculations.
"Floating point" is good for very big numbers and very small numbers. It is not much use for numbers of your size due to processing overheads anyway. If you are taking a CSV from Excel in a number of financial applications, you may well see a true "floating point" number. Looks nothing like yours. Yours is a piece of text with a decimal point in a varying position.
I tried to point this out shortly to you originally to aid your search for a solution. I thought to myself, "if this guy is looking up floating point, he's not going to find the answer except by accident".
When you say something is such-and-such, and someone else says "no it is not", next time check rather than just saying "yes it is", which is no help to you at all. Sometimes you'll be right. This time, not.
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
Quote:
Erm.. Its SYNCSORT which we are using!
Not to worry about that. Here's an example syncsort job which does what you're trying. You could tweak this to make it work for your actual requirement