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.
>
>
>OK, I haven't been able to look at the "C" code, and I don't know "C"
>very well, YET! The "C" prog'r doesn't know the "HP" very well, so he
>asked me the following question:
>
>******
>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.

However, I believe the following method:

      MOVE CORR SOURCE-DATA to LINIKAGE-AREA.

will cause the over-punched 'item-3' to be converted from '000}' to
simply BINARY '0000' in the target 16-bit address as a part of the
move verb.

If this doesn't seem to be it, let me know off-line and I see if I
can offer some other things to check.