Field1 is coming from the input file which I can not change and field2 is a field of the table. I can not change it either. But I will have to populate field2 withe field1. I guess this calirify your doubts.
Joined: 20 Oct 2006 Posts: 6968 Location: porcelain throne
Rarely does Akatsukami use such strong words when commenting.
He, by the way, had no doubts about the technical matter.
If he had any doubts at all, it was about your capabilities and skills.
now, comp-5 is binary.
(by the way, both fields are numeric)
field2 is a field of the table.
that can only interpreted as a field of an item of a COBOL Internal Table.
you are not talking about a DB2 column, because the SCALE of a column is always 0 if the datatype is not DECIMAL.
So, back to your COBOL field definitions. Why is the field2 defined as BINARY instead of PACKED-DECIMAL?
if your answer is the the table was designed that way, and I can't change it
the you need to speak to the designer, because his knowledge base is also severely lacking.
and you should refrain from snide, insipid retorts,
especially if you want help,
and you definitely need it
Joined: 03 Oct 2009 Posts: 1775 Location: Bloomington, IL
Priyanka, you have offered no evidence that the value of your display variable is or isn't being moved to your COMP-5 variable. However, I will offer a method of producing such evidence. Other senior members may provide preferable methods.
At some point in your program, you probably have a statement like:
MOVE DISPLAY-VARIABLE TO COMP-5-VARIABLE.
Follow it immediately with the statement:
CALL 'CEE3ABD' USING FOO, BAR.
In the WORKING-STORAGE section, declare:
01 FOO PIC 9(8) BINARY VALUE something less than 4096.
01 BAR PIC 9(8) BINARY VALUE 1.
This will cause your program to abend -- an actual, honest-to-Kamisama abend, not a JCL error, non-zero return code, scary and mysterious message, or any of the other yivshish that your colleagues miscall abends.
Find DISPLAY-VARIABLE and COMP-5-VARIABLE in one of the dumps -- for the moment, I will presume that you can do this. Copy and paste the code executed just before CEE3ABD is called, and the lines from the dump containing the storage for the variables in question. If you do this, we can proceed.
I'd suggest you also produce the pseudo-assembler that the compiler generates when you make Akatsukami's "changes".
Maybe add some code after the call, just to do some simple maths so you can see what is generated. It will probably be pretty horrible, but that is what your fields are going through with that definition.
Look up the documentation for your "table" and tell us the reason the field is defined that way, please.
Other nice ways to dump, add one to a non-initialised comp-3 field, call "foo". The last I always found the quickest. I like DISPLAY for information about known problems, when there is something I don't yet understand, I like a dump - no double entendre intended :-)