HP3000-L Archives

January 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Thu, 11 Jan 1996 23:53:10 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (30 lines)
On Thu, 11 Jan 1996 19:44:43 -0500 James R. Alton said:
>On Fri, 12 Jan 1996, Leon Degeling wrote:
>> When I call a c-program is always pass strings. For this purpose I allways
>> convert my int and longs into ascii. This is rather silly so I want to pass
>>ints and longs directly. However I don't know which decarations I should use
>>on the cobol side. I've tried a lot of them but results are somewhat wacky.
>>
>> so              char[10]       = pic x(10)
>>                 int            = pic ?????
>>               long             = pic ?????
>>              float[]           = pic ?????
 
Thus is a trick question :-)
 
A short is a pic s9(4) comp
    int is a pic s9(9) comp [being that native MPE/iX C 'int' is 32-bit]
   long is a pic s9(9) comp
  float is yet to be added to COBOL but it's in the specs for next release
But that isn't the whole story.
 
The trick is two-fold.  If you use the 'sync' attribute you can run into
trouble, especially when converting "classic" COBOL.  If you don't use the
'sync' attribute, COBOL doesn't align it's fields at all.  For safety, any
time you pass a non-string (short/int/long) to a C routine, you should first
memcpy() the parms to local storage defined in the C routine which will be
properly aligned.  And any return parms should also be memcpy()ed back to
the respective variables.  memcpy() doesn't care about alignment.
 
Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2