where C388-IMP-SOLICITADO is the S9(15)V9(2) COMP-3 receiving variable. The displays and errors we are getting are as follows:
CEE3207S The system detected a data exception (System Completion Code=0C7).
From compile unit KGCRGH25 at entry point KGCRGH25 at statement 1908 at
entry offset +000049A4 at address 4198D9A4.
<> LEAID ENTERED (LEVEL 06/15/2011 AT 18.20)
<> LEAID PROCESSING COMPLETE. RC=0
COBOL is not my thing, so i've been reading around and I think the comma migth be giving us trouble. ¿Is that the cause of the problem?
Is there a way arond this?
the input variable will always have the previous format, that is, 13 integer, a comma and two decimals
IF ( a-nice-name-for-integer-part NUMERIC )
AND ( a-nice-name-for-decimal-part NUMERIC )
AND ( a-nice-condition-for-valid )
MOVE a-nice-name-for-integer-part TO another-nice-name-for-integer-part
MOVE a-nice-name-for-decimal-part TO another-nice-name-for-decimal-part
MOVE a-nice-name-for-pic-9-13-v99 TO your-comp-3-field
MOVE ZERO TO your-comp-3-field
or something else appropriate
Joined: 06 Jun 2008 Posts: 8195 Location: East Dubuque, Illinois, USA
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.