IBM Mainframe Forum

Hi Billy,

My requirement was to multiply 2 numbers.
Var 1 --> 9(16) PD
Var 2 --> 9(5)v9(10) ZD
When I multiply these 2 numbers I lost leading 10 digits.

If I give small value, It works fine, Max value it can hold after multiplication is 9(19)v99.

If the integer part is more than 19 bytes then it would be a problem.

In SAS I declared var3 with 16.2 PD
When I did the multiplication , Var3=var1*var2, It is automatically rounded the multiplied value to 16.2 PD (COBOL equivalent for your reference 9(14)v99)

Don't you agree that we need a lot of logic in SORT just to round the value??
Don't you think, Its time to have internal function which does it??

Hello,

Don't you agree that we need a lot of logic in SORT just to round the value??

No, the sort does Many things. It does NOT do everything. If you are determined to do full-function report writing in a SORT process, consider an exit to do the formatting.

Don't you think, Its time to have internal function which does it??

Not really. If enough users want this, it will most likely happen at some time.

Unfortunately for many, Some Work still has to be done . . .

Are you sure about the size of 16.2 PD in SAS? From your COBOL translation, that is much shorter than the data you have shown.

The point about the rounding is that there is more than one type of rounding. When you say rounding, you have to be specific. SORT rounds down. It is a rounding, not the one you want.

If SAS has the advantage of knowing about the scaling of your second field. If SAS is multiplying your 29 digit plus two decimal places value by five with 10 decimal places, SAS has a bit of extra space to work with, but 29 + 5 is 34, so if you have a value sufficiently large that you are multiplying by, you will still have truncation.

If your multiplier is never large enough to break it (so why is it defined so big?) then you may get a result from SORT by DIViding by the reciprocal (divide your multiplier into one, then DIV by the result).

You haven't answered on the range of values your 9(5)V9(10) can take, so don't know if you still may get truncation in SAS.

If you define your rounding, it can be done in SORT through code.

If you are looking for additional functionality in DFSORT so apply a specific rounding (one of more than one possible "roundings"), then Kolusu will probably comment on that. There will certainly not be a change to the way the basic code works, cos it would break existing sort control card decks and backwards compatability is exceptionally important.

shankar_dh wrote:When I multiply these 2 numbers I lost leading 10 digits.

If I give small value, It works fine, Max value it can hold after multiplication is 9(19)v99.

If the integer part is more than 19 bytes then it would be a problem.

In SAS I declared var3 with 16.2 PD
When I did the multiplication , Var3=var1*var2, It is automatically rounded the multiplied value to 16.2 PD (COBOL equivalent for your reference 9(14)v99)

Don't you agree that we need a lot of logic in SORT just to round the value??
Don't you think, Its time to have internal function which does it??

Shankar_dh,

In DFSORT the resulting values are rounded down to the nearest integer. Which programming language supports more than 31 digits currently? Even SAS only supports 31 digits for packed decimal values.

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.

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.

Shankar_dh,

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.

As Kolusu is indicating, multiplying that value by 60 you'd expect truncation. There is no way you can get the correct answer and store it in 29 integer digits plus two decimal places.

That's 23,435 trillion trillion anyway. Let's say the current annual GDP of the US is 16 trillion. That would mean you'd have enough space in your field to hold over 1,400 trillion accounts the size of the US of A. I haven't even bothered to check my maths, as I could be several orders of magnitude out and you'd still be looking at an absurd number of accounts of an absurd size.

Why are you taking the summed value of balances and doing a currency coversion?