IBM Mainframe Forum

Hi,
I have a requirement to move a variable of datatype 9(0012)V9(04) to S9(14) COMP.
Fortunately, the field does not cross a value of 100.0000.

I have tried the below code but the output seems incorrect interms of positions.



When SFD02-MBS-VAL is 93.0720 I would expect 9307200000 in POSOUT-RATE. But I receive 930720.

Could anyone help?

Even assuming that you mean POSOUT-AMORTN-RATE not POSOUT-RATE, we will be unable to say too much because we do not know why you are expecting that particular output, we don't know what output you want exactly.

It is likely that your required result can be achieved with one or two simple MOVEs. There is certainly no need to use UNSTRING on an actual decimal place, because the original values are all in a fixed position anyway. You don't need UNSTRING to split the integer part from its decimal.

1. Sorry POSOUT-AMORTN-RATE is POSOUT-RATE.
2. POSOUT-RATE is existing in the code and it should now receive a value from SFD02-MBS-VAL. When SFD02-MBS-VAL is 93.0720 I would expect 9307200000 in POSOUT-RATE. But I receive 930720.
3. Also I have tried to move without UNSTRING and yet receive the same result.

You have still not explained why you expect that result. At least you didn't just multiply it by 10,000 and get on with it.

01 SFD02-MBS-VAL PIC 9(0012)V9(04).
01 WS-MBS-VAL-TRUNC-L-EXTEND-R PIC 9(3)V9(9).
01 WS-MBS-ALIGNED-NO-DECS
REDEFINES WS-MBS-VAL-TRUNC-L-EXTEND-R
PIC 9(12).
01 POSOUT-RATE PIC S9(14) COMP.

MOVE SFD02-MBS-VAL TO WS-MBS-VAL-TRUNC-L-EXTEND-R
MOVE WS-MBS-ALIGNED-NO-DECS TO POSOUT-RATE

Why is POSOUT-RATE binary?

Hi Billy, Thanks for the code. I tweaked a little and it fit my requirement. Regarding your question on why is POSOUT-RATE Binary - This variable is passed further to other subroutines where it is expected to be Binary.

OK. The length of that field is going to be eight bytes, a double-word. That field-size can hold 18 digits. If you are defining 14 digits, then you should ensure that nothing down the line can ever use more than 14 digits, because if it does, your program may not be aware of them.

You say that your input value can never be greater than 100. If you want to check that that is the case in the program (I mostly do that, unless it really, really, can never be above 100 (or whatever)) the truncated-and-expanded field should still be equal in value to the original field. I'd test that, and do something (per your local standards or by consulting the analyst who wrote the spec) if it is not.

Typical conversation:

Me: That's going to get truncated if it is above 999.

Them: Not a problem, it can never be above 100.

Really? What shall I do if it is above 100?

Nothing. Can't happen.

OK. (then codes IF > 100, abend, spec says this can never happen).

If it happens, it usually happens in system-testing (analyst's cheeks become a little reddened). If it never happens, doesn't matter much unless performance is critical.

The point it, if you are the one truncating, then you should be check that no value is being truncated, unless it really, really, cannot exceed that value. Really. The test is inconsequential, so it's in, is the way I look at it.

Billy, You are right. The SFD02-MBS-VAL variable holds values upto 10000000.0000.
The requirement is now finalised.
My requirement now is to move MBS-AMORTN-VAL PIC 9(0012)V9(04) to WW-NR-RATE PIC S9(14).
Could you please let me know if there would be any possible data truncation?

I have tried the below code.


There seems to be a problem with Decimals.
When SFD02-MBS-AMORTN-VAL : 58093.0720 NR_RATE = 58.0930720

Could you please extend your support?

Please use the code tags when posting code/data/JCL/control data. They preserve any spacing and make it stand out from the prose.

What is the definition of WW-NR-RATE?

Sorry for that. WW-NR-RATE PIC S9(14).