shankar_dh wrote:Sorry, COBOL equivalent of PD16.2 is 9(29)v99
Basically 9(5)v9(10) is to hold the currency exchange value. So I guess, Integer part can not be more than 3 digits. Only the decimal place will be more which will occupy all the 10 digits.
For ex, 1 USD = 60.2354809765 INR
Say Your balance is $ 23,435,234,091,765,097,765,124,678,009.87 --> This is stored in PD16.2 ( I am sure Balance can not be this much huge , This is just for example)
So while multiplying your account balance -- Your balance in USD * 60.2354809765 = Converted value in INR which should be in 9(29)v99 [PD16.2]
In SORT you need to have a logic to ROUND the multiplied value to 9(29)v99 but in SAS I did not use any logic, just declared variable of length PD16.2 and stored the multiplied result.
Yes, DFSORT is very strong TOOL. But I am feeling in this case it is the limitation. Rather we should have had internal function which takes care of the ROUNDING the results after arithmetic operations.
23,435,234,091,765,097,765,124,678,009.87 X 60.2354809765 = ?????? how much in SAS? is SAS truncating it to the left or right? You are looking at an imaginary number and think it is a limitation of DFSORT but it isn't.