At 06:50 AM 6/13/97 -0500, Jerry Fochtman wrote:
>At 01:51 AM 6/13/97 -0700, John D. Alleyn-Day wrote:

>>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.
>
>Yep, I'd overlooked this aspect of alignment.  Which brings-up another
>possibility for this problem.  Certainly we don't know how the 'C' program
>is displaying the address space.  We also don't know how the 'C' programmer
>declared the integer variable.  If the expectation is to receive an integer
>it is fairly normal for the 'C' programmer to use 'int' to declare the
>receiving variable.  This would define a 32-bit/4-byte integer instead of
>the proper 16-bit/2-byte integer using a 'short' declaration.  If this is
>the case, then it is quite possible that a look at this variable on the 'C'
>side would indeed contain the ASCII '000}' value given a record-level type
>move.  Subsequent field alignment may appear to be correct because of the
>4-byte spacing used by the display picture in the record-level move would
>align with the 4-byte 'C' integer declaration. So from the 'C' side it
>could appear aligned but have the ASCII '000}' content in the 32-bit,
>4-byte int, with item-4 aligning correctly on the 'C' side.

Still the same problem.  If the field is defined as "int" the "C" program
would read it as 30303030 hex.  You still can't get ASCII characters in an
integer field.  I stll think the problem arises on the "C" side.  Or else
the COBOL program has it defined as a s9(4) and the "C" program as a char
array.
>
>I'm not sure we really have enough info yet to know the specific cause for
>the content and possibly alignment problem.  Could really be a couple of
>problems going on.....
>
I agree.  We need more information.  Actually, I suspect the search for
more information will disclose the answer.

John D. Alleyn-Day
Alleyn-Day International
408-286-6421   408-286-6474 (Fax)
[log in to unmask]       http://www.Alleyn-Day.com