Page 1 of 3
COBOL Move
Posted:
Fri Mar 07, 2014 11:55 am
by maragatham pp
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.
01 SFD02-MBS-VAL PIC 9(0012)V9(04).
01 POSOUT-AMORTN-RATE PIC S9(14) COMP.
01 WS-RTE.
05 WS-RTE-1-6 PIC X(12).
05 WS-RTE-7-14 PIC X(04).
01 WS-RTE-R REDEFINES WS-RTE PIC 9(16).
01 WS-MBS-RTE PIC S9(14).
01 WS-FMT-RTE PIC 9(12).9(4).
01 WS-FMT-RTE1 PIC X(18).
MOVE SFD02-MBS-VAL TO WS-FMT-RTE.
MOVE WS-FMT-RTE TO WS-FMT-RTE1.
UNSTRING WS-FMT-RTE1
DELIMITED BY '.'
INTO WS-RTE-1-6 WS-RTE-7-14.
IF WS-RTE-R(1:2) = ZEROS OR SPACES
MOVE WS-RTE-R(3:14)TO WS-MBS-RTE
END-IF.
MOVE WS-MBS-RTE TO POSOUT-RATE.
When SFD02-MBS-VAL is 93.0720 I would expect 9307200000 in POSOUT-RATE. But I receive 930720.
Could anyone help?
Re: COBOL Move
Posted:
Fri Mar 07, 2014 12:49 pm
by BillyBoyo
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.
Re: COBOL Move
Posted:
Fri Mar 07, 2014 1:03 pm
by maragatham pp
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.
Re: COBOL Move
Posted:
Fri Mar 07, 2014 1:30 pm
by BillyBoyo
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?
Re: COBOL Move
Posted:
Fri Mar 07, 2014 5:12 pm
by maragatham pp
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.
Re: COBOL Move
Posted:
Fri Mar 07, 2014 6:50 pm
by BillyBoyo
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.
Re: COBOL Move
Posted:
Wed Mar 12, 2014 1:20 pm
by maragatham pp
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?
Re: COBOL Move
Posted:
Wed Mar 12, 2014 2:44 pm
by maragatham pp
I have tried the below code.
01 WS-MBS-VAL-TRUNC-L-EXTEND-R PIC 9(12)V9(4).
01 WS-MBS-ALIGNED-NO-DECS-R
REDEFINES WS-MBS-VAL-TRUNC-L-EXTEND-R PIC 9(16).
MOVE SFD02-MBS-AMORTN-VAL TO WS-MBS-VAL-TRUNC-L-EXTEND-R
MOVE WS-MBS-ALIGNED-NO-DECS-R TO WW-NR-RATE
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?
Re: COBOL Move
Posted:
Wed Mar 12, 2014 4:38 pm
by NicC
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?
Re: COBOL Move
Posted:
Wed Mar 12, 2014 4:45 pm
by maragatham pp
Sorry for that. WW-NR-RATE PIC S9(14).