[Info-vax] Returning data from Cobol AST routine.

[Arne Vajhøj]

On 9/21/2021 8:31 PM, Jan-Erik Söderholm wrote:
> Den 2021-09-22 kl. 01:31, skrev Arne Vajhøj:
>> On 9/21/2021 6:55 PM, Jan-Erik Söderholm wrote:
>>> This ACCVIO's on the display statement. The weird thing is that
>>> the virtual address in the ACCVIO message is ...00042D, and that
>>> is the hex for the value I used, in decimal 1234.
>>>
>>> I must be missing something, it looks like the display statement tries
>>> to use the value in reqidt as an address instead of the actual value...
>>
>> I know next to nothing about COBOL, but if COBOL use call by ref as
>> default like FORTRAN, so that the AST routine expects an address,
>> then the error makes sense.
> 
> Right. When calling *from* Cobol you can specify "by ref", "by val"
> and so on. I have looked but I cannot find anything similar when a
> Cobol routine is *called*. But yes, it very much looks like that a
> called Cobol routine expects a "by ref" (pointer) parameter.
> 
> But the SETIMR docs says that this parameter is sent by value.
> 
>> And the solution could be to call with
>> address of reqidt in main code (I don't know how to do that i COBOL
>> but it must be possible).
>>
> 
> Good point... And that solved this issue!
> 
> 
> 01  reqidt              pic 9(9)    comp.
> ...
>      move 1234 to reqidt
>      call "sys$setimr"
>          using omitted
>                by reference delta-time
>                by value ast-proc-addr
>                by reference reqidt    <<==
>                omitted
>          giving return-value
>      end-call
> 
> Replaced "by value reqidt" with "by reference reqidt".
> That will pass the address (pointer) to reqidt.
> Silly not thinking about that...
> 
> The AST routine just uses the paramater as-is as before
> an now prints "reqidt: 1234" as expected.

I would probably have preferred to keep the formal
argument as by val and stuffed the address into an integer
and passed that. Slightly more complicated but I just
don't like faking the passing mechanism of a system
service.

Arne