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

[Jan-Erik Söderholm]

Den 2021-09-22 kl. 03:37, skrev 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
> 

Not that much more complicated, one additional pointer definition:

01  reqidt_addr         pointer     value reference reqidt.
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 value reqidt_addr
               omitted
         giving return-value
     end-call

This also works. A matter of taste, I guess. :-)

Now, a bigger issue is that I found this in the Rdb docs:

------------------------------------------------------------
15.3 Avoiding Asynchronous System Traps

You should not use asynchronous system trap (AST) service routines in
an application that accesses Oracle Rdb databases. If you do, Oracle
Rdb cannot guarantee the behavior of the application.

Because several Oracle Rdb components use AST service routines and
because an AST cannot be delivered while an AST service routine is
currently executing at the same mode or more privileged mode, using
an AST service routine in an application can prevent the delivery of
an AST in one of the components of Oracle Rdb.
------------------------------------------------------------

I posted a question on the Rdb mailing list regarding ASTs, and got
this from, what I regard as, an trustworthy source:

------------------------------------------------------------
Seems pretty clear. At any access mode the program can be either in
non-AST or AST mode.

As long as you are very well aware of this, make certain that your
AST-mode code does whatever it does, never calls anything related
to Rdb, and then exits, you are probable just fine.  Do not do
anything that might block (e.g. potential synchronous IO or similar;
explicitly avoid RMS directly or indirectly).

Best that you studiously avoid anything to do with timers or
$HIBER/$WAKE to make your future life easier.
------------------------------------------------------------

It is very much the general guidelines for any interrupt handling
on any kind of environment (have done PIC microcontroller work before).
In all cases, keep your interrupt (or AST) rooutines as short as
possible and let the main code do the processing...

We'll see. Still under investigation.