[Info-vax] COBOL PIC format for a 64 bit unsigned int ("long long") ?

[Jan-Erik Söderholm]

Jim Duff wrote:
> Jan-Erik Söderholm wrote:
>> I am trying to call some COBOL code from a piece of C...
>>
>> The call from C looks like this :
>>
>>  char cob_inart[16];
>>  unsigned long long cob_insernr;
>>  char cob_utben[16];
>>  char cob_utordnr[16];
>>  int rc;
>>
>>  rc = MES101(cob_inart, cob_insernr, cob_utben, cob_utordnr);
>>
>> I get a ACCVIO when trying to use the "unsigned long long"
>> paramater on the COBOL side. I have probably not got the
>> right PIC clause to match the "unsigned long long", I guess.
>>
> 
> "Trying to use" is defined as what?  Can we see either the code that
> produces the error or the error itself?  Preferably both.
> 
>> Currently it looks like this (in MES101.COB) :
>>
>>  WORKING-STORAGE SECTION.
>>  01 Answer             PIC S9(9) COMP.
>>
>>  LINKAGE SECTION.
>>  01 c_inart            PIC X(16).
>>  01 c_insernr          pic 9(16) comp.
> 
> 
> Your COBOL picture clause for the quadword is not wide enough.
> 
> 
>>  01 c_ben              PIC X(16).
>>  01 c_ordnr            PIC X(16).
>>
>>  PROCEDURE DIVISION USING c_inart c_insernr c_ben c_ordnr
>>                           giving Answer.
>>
>> As soon as I try to do anything  with the "c_insernr"
>> paramater (such as DISPLAY or MOVE) the COBOL code ACCVIO's.
>>
>> Does anyone have a clue what the PIC clause should look
>> like to match a "unsigned long long" ?
>>
> 
> Try PIC 9(18) COMP.
> 
> See <http://h71000.www7.hp.com/doc/82final/6297/6297pro_097.html#vms_usages>
> 
>> And yes, I have scanned the COBOL and C User Guides and
>> Ref Manuals, but didn't find anything clear on this point.
>>
>>
>>
> 
> Working example:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main (void) {
> 
>     extern int MES101 ();
> 
>     char cob_inart[16] = "INART";
>     unsigned long long cob_insernr = 123;
>     char cob_utben[16] = "UTBEN";
>     char cob_utordnr[16] = "UTORDNR";
>     int rc;
> 
>     rc = MES101 (cob_inart, cob_insernr, cob_utben, cob_utordnr);
> 
>     exit (EXIT_SUCCESS);
> }
> 
> 
> identification division.
> program-id. MES101.
> environment division.
> data division.
> working-storage section.
> 01 answer             pic s9(9) comp.
> linkage section.
> 01 c_inart            pic x(16).
> 01 c_insernr          pic 9(18) comp.
> 01 c_ben              pic x(16).
> 01 c_ordnr            pic x(16).
> 
> procedure division using c_inart c_insernr c_ben c_ordnr
>                           giving Answer.
> 00-begin.
>     display c_inart.
>     display c_insernr with conversion.
>     display c_ben.
>     display c_ordnr.
>     move 1 to answer.
> 01-end.
>     exit.
> 
> Jim.

Outputs "INART" (as expected) and then ACCVIO's on the
second DISPLAY. Anyway, see below...

glen herrmannsfeldt wrote:

 > I don't know specifically about COBOL, but calls from C to
 > many other languages expect the address of, not the value of,
 > the arguments.  For arrays that happens sort of automatically
 > (an array name is a constant pointer to the first element),
 > but not for scalars.  Try an & in front of the non-array.

and Richard Mahrer wrote :

 > Try telling C to send it by reference,


Tried that in Jim's code above, and that made it for his
test code.

And also for my original code. I changed the type of the
"unsigned long long" variable into a "pointer to unsigned
long long", but the effect is the same...

Richard Mahrer also wrote :

 > Why you'd be using a quadword to store what is presumably
 > an error number (or using C at all for that matter)
 > I don't know.

"I don't know" is the key here. No, it's not an "error number".

It's a manufacturing serial number like "yyyywwnnnnn" where
"yyyy" is year, "ww" is the week and "nnnnn" is a counter.

Now this *could* just as well have been a string (no calculations
needed), but it isn't. It's a "bigint" in the Rdb database. Yes,
I could have passed it as a string from the Office/Excel application
and made the string->bigint convert in the COBOL code, and that
would probably have been the "solution" if the "ByRef" (&) above
hadn't worked. But right now it's passed it as a "number" and
I'll see how which way I take in the final code.

B.t.w, FWIW, this is part of the production lines of this kind of stuff :

http://www.douglaslawnmowercentre.com/training/images/front/h560-0012.jpg