Jerry Fochtman wrote:

>At 10:07 PM 6/11/97 -0500, Michael Anderson wrote:
>>I have a COBOL subroutine that, I wrote about seven or eight years ago.
>>It's LINKAGE is:
>>
>>Abrv Example:
>>
>>01 LINIKAGE-AREA.
>>   02 DATA-ITEM-1  PIC X(20).
>>   02 DATA-ITEM-2  PIC X(80).
>>   02 DATA-ITEM-3  PIC S9(4) COMP.
>>   02 DATA-ITEM-4  PIC XX.
>>
.....................................
>>You passed me all the data correctly, I got Item-1, Item-2, and Item-4
>>exactly the way I expected to get'em, but Item-3 came to me like this
>>"000}" --- Why do ya think that is?
>>******
>
>Many folks have explained how to interpret the zoned-overpunch 'zero'
>character.  However, in COBOL zoned overpunch only is used in display-type
>pictures, such as PIC S9(4).   In this base, the clause "COMP" indicates
>simply a 2s-compliment binary storage space.  I suspect that the data
>being placed in this area is coming from another record structure whereby
>this element is defined as a display-type picture and the MOVE verb
>is doing a record-level to record-level move, not a MOVE corresponding,
>thus not converting the different picture types of the 'item-3' element.
>
>For example, suppose the source area was:
>
>    01 SOURCE-DATA.
>       02 DATA-ITEM-1  PIC X(20).
>       02 DATA-ITEM-2  PIC X(80).
>       02 DATA-ITEM-3  PIC S9(4).
>       02 DATA-ITEM-4  PIC XX.
>
>In this record structure, 'item-3' would be '000}'.  If this is moved
>to the target record structure above by:
>
>      MOVE SOURCE-DATA TO LINIKAGE-AREA.
>
>there will be no conversion of 'like' elements to the defined picture
>of the target.  As such, even though the picture clause of 'item-3'
>indicates a strictly binary value, the address of this element in the
>stack will contain the data based upon the picture of the source element.
>
This doesn't explain the problem.  The s9(4) item is display (ASCII) and
occupies 4 bytes, whereas the s9(4) COMP item is only 2 bytes.  So, if the
"MOVE" was not a "MOVE CORR" data-item-3 would overlap data-item-4 by two
bytes and you should have gotten a truncation error when compiling.
Furthermore, since an ASCII "0" has a value of 30 hex, what the "C" program
would get in its integer field would be 3030 hex or 12336 decimal.  And,
lastly, data-item-4 would not be received correctly.

I would suspect something in the "C" program.  You just can't get a "}" in
an integer field, by definition.  I don't know HP "C", but I would suspect
that the program receives it correctly, and it's being displayed with the
overpunch character.

Jim Phillips gave the necessary definitions of the fields in his previous
e-mail.  Have the "C" programmer look at the integer being passed at a more
fundamental level.  Repeat, you cannot possibly get a "}" in an integer or
comp field.