COBOL Move



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

COBOL Move

Postby maragatham pp » Fri Mar 07, 2014 11:55 am

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?
maragatham pp
 
Posts: 19
Joined: Fri May 20, 2011 12:44 pm
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL Move

Postby BillyBoyo » Fri Mar 07, 2014 12:49 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: COBOL Move

Postby maragatham pp » Fri Mar 07, 2014 1:03 pm

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.
maragatham pp
 
Posts: 19
Joined: Fri May 20, 2011 12:44 pm
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL Move

Postby BillyBoyo » Fri Mar 07, 2014 1:30 pm

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?
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: COBOL Move

Postby maragatham pp » Fri Mar 07, 2014 5:12 pm

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.
maragatham pp
 
Posts: 19
Joined: Fri May 20, 2011 12:44 pm
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL Move

Postby BillyBoyo » Fri Mar 07, 2014 6:50 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: COBOL Move

Postby maragatham pp » Wed Mar 12, 2014 1:20 pm

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?
maragatham pp
 
Posts: 19
Joined: Fri May 20, 2011 12:44 pm
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL Move

Postby maragatham pp » Wed Mar 12, 2014 2:44 pm

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?
maragatham pp
 
Posts: 19
Joined: Fri May 20, 2011 12:44 pm
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL Move

Postby NicC » Wed Mar 12, 2014 4:38 pm

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?
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 3025
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisies (almost)
Has thanked: 4 times
Been thanked: 136 times

Re: COBOL Move

Postby maragatham pp » Wed Mar 12, 2014 4:45 pm

Sorry for that. WW-NR-RATE PIC S9(14).
maragatham pp
 
Posts: 19
Joined: Fri May 20, 2011 12:44 pm
Has thanked: 0 time
Been thanked: 0 time

Next

Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post