[...good discussion of overpunch snipped...]

I think we figured out the overpunch adequately, but I wanted to point
out a few other concerns between C and Cobol...

* COBOL has very lax alignment requirements.  While 01 and 77 level
  items will start on a 32-bit boundary (native mode), there is by
  default no padding within these "structures", e.g.:

  01  foo-struct.
      02  foo-char     pic x.
      02  foo-int      pic s9(9) comp.
      02  foo-char-2   pic x.
      02  foo-short    pic s9(4) comp.

  This will layout storage consecutively, ignoring alignment issues,
  as COBOL will generate proper code to 'handle' these cases.  Above
  we allocate 8 bytes with no "slack bytes".

  But if the COMP items are defined as COMP SYNC, one of two things
  happens -- depending on the $CONTROL SYNCxx setting (SYNC16/SYNC32).
  Only in the SYNC32 case will it match native C/iX structure layouts
  in terms of alignment and slack bytes.  The more prevalent SYNC16
  usage (carry-over from COBOL/V conversions) still allows an 'int'
  to reside on a 'short' boundary.

* Because of alignment issues, you are better served by creating a
  union of an int and a char locally, and memcpy the passed 'int'
  into your char; afterwards you can deal with the int.  Be sure to
  copy it back when you return.

* Be careful dealing with COBOL pic(x) items - so many are tempted to
  use string operations on them.  If you must, memcpy() the COBOL data
  to local vars and null-terminate them beforehand, then copy them back
  afterward.

Jeff Kell <[log in to unmask]>