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

[Bob Gezelter]

On Wednesday, September 22, 2021 at 3:41:15 AM UTC-4, Jan-Erik Söderholm wrote:
> 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.
Jan-Erik,

Yes, that comment in the Oracle RDB documentation is the point that I was referring to in my DECUS seminar. The solution is to have the main thread read from an interlocked queue.

- Bob Gezelter, http://www.rlgsc.com