Hi, I am doing a change in COBOL pgm in as400. Requirement is to replace an existing input file with a new one and move its field values to the output file. There is a difference here as old input file had the particular field in numeric and the new input file has it in decimal. I have used COPY DD-ALL-FORMATS OF [new][/new]just like how the old file was. I could avoid compile error after I gave move of this field to a variable of PICX(3). But now while debugging the code; I'm getting decimal data error. How will i decalre or move from decimal file ? Or do I have to convert this decimal data before i do move? or is there any other way. Note: I'm little new to programming but I guess this question is clear? Any help suggestion is greatly appreciated
Software/Hardware used:
as/400
ASKED:
June 18, 2010 1:48 PM
UPDATED:
September 27, 2010 5:45 PM
But now while debugging the code; I’m getting decimal data error. How will i decalre or move from decimal file ?
My suggestion is to show us (1) the definitions of both fields and (2) the value in the source field since you can see it in debug. If we don’t know the definitions and the value, we can only give guesses. The guesses won’t include any directions on what you might need to change.
Tom
Thanks Tom,,
abt (1) to show the definition of fields, old input file was defined as copy all COPY DD-ALL-FORMATS OF. Opening that file in sql I could see the field is of numeric length 3. The out put file to which this field is moved PIC X(070).
Now the new input file, i have used the same COPY DD-ALL-FORMATS OF in the COBOL, but the field is of decimal length 3. This is being moved into the same output file PIC X(070).
(2) Value is coming as 404 where as the actual value of the field should be read as 019
I am not sure whether this new field needs to be converted from decimal to other form ? Or is issue in declaring this input file. I do not think I can change the output file format to which it is being moved. May be issue in declaring this new file ???
the field is of decimal length 3. That information is one piece. This is another: Value is coming as 404.
Together, those indicate a very good chance that the field has not been initialized. When a packed decimal value shows only the digits {40}, there is always the chance that blanks are part of the field.
A 3-digit packed decimal field takes two bytes. Two bytes of blanks would have a hexadecimal value of x’4040′. The last position would be reserved for the numeric sign — positive or negative. So the digits portion would be ’404′.
If you are using SQL, how are you using the /COPY statement? Hopefully, it is in the WORKING-STORAGE section.
The decimal-data error is almost certainly caused by an invalid sign, probably caused by improper initialization of the field. There has been no value assigned to the packed-decimal field, so it remains as blanks. When you try to convert the packed value to a character representation, the invalid sign signals a data error.
However, since you still haven’t shown the field definitions nor the statements that get the error nor the statements that set the values, it’s still a guess.
Tom
yes Tom, the issue was with the fiel defnition, I changed it to COPY DD-ALL-FORMATS OF FILE-NAME and used the fields and i could overcome this issue. Initially i had to change this way because of other issues. But after fixing that i forgot to revert this…
once again thanks for the help !!