Your first problem is that your PICTURE clause does not match your data. The V in a PICTURE means IMPLIED decimal point -- as in, it does not really exist in the data. Also, the data is not signed so why use the S on the PICTURE clause? Try 9(13).9(2) instead of S9(13)V9(2). Also, your filler should be 4 and not 5 since the decimal point counts as one of the 20 characters.

I can't change de S on the picture clause in the receiving variable because in this shop, it belongs to a copy that comunicate with a routine of a different department and is already in use in production. That said, I think then that indeed the comma is the cause of my problems. So the V only tells where the decimal point is, but not the existance of a comma, I should process the integer and decimals by separate?

Could be possible to move redefine the input variable as an numeric edited varibale, and then move this to the numeric destination variable? Something like this?:

Robert, Bill. I've got exactly what you've been trying to tell me. Thanks a lot. The input variable is validated in a front app and I'll always receive the data in that format, so there is a very low, to non existant, risk of receiving inconsistant data on that variable.With that, I know that I'll always receive 13 integers, a comma and 2 decimals, so the last example given by Robert is just what I needed to acomplish this.

I'll simplify the memory definition of the variable, changing the redefines by two variables that sums 20 bytes and use that solution.

BTW, I prefer to write the numeric edited variables with a long string of 9's or other characters because that way I identify them easily as numeric edited instead of regular variables.