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

[Jan-Erik Söderholm]

Den 2021-09-22 kl. 01:31, skrev Arne Vajhøj:
> On 9/21/2021 6:55 PM, Jan-Erik Söderholm wrote:
>> Den 2021-09-22 kl. 00:22, skrev Arne Vajhøj:
>>> On 9/21/2021 5:21 PM, Jan-Erik Söderholm wrote:
>>>> Trying to find a better design, now that we hav a need for some
>>>> major application redesign anyway for other reasons.
>>>>
>>>> And, if we do have any non-AST-compatible code in the main code, I'm
>>>> also looking for some disable/enable AST functions. They are probably
>>>> there, just have to look it up.
>>>
>>> You may get a much more robust solution by using your IBM MQ instead
>>> of a VMS mailbox.
>>>
>>> No AST's and problem with number of messages.
>>
>> Ah, well. Yes, some message queing tool might also be an option.
>> And we do use IBM MQ but only for external communication to the
>> corporate message bus center. There is no MQ server on VMS only
>> client, so a local MQ solution will be hard.
> 
> If you have Itanium then you could install the ActiveMQ kit
> from VSI. But even with Alpha you could maybe install ActiveMQ
> on a Linux VM and use that from VMS. Open source => do not
> need approval for CAPEX spend.
> 
>> I kind of like the simplines of mailboxes, in particular since
>> we got the CREATE/MAILBOX DCL commands. Very simple to setup.
> 
> ActiveMQ can auto create queues at first reference.
> 
> :-)
> 
>> At the moment I'm trying to get the reqidt parameter of the SETIMR
>> call to work. It should be sent as a parameter to the AST routine.
>>
>> In the main code:
>>
>> 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
>>                omitted
>>          giving return-value
>>      end-call
>>
>>
>> In the AST routine:
>>
>> linkage section.
>> 01  reqidt             pic 9(9)   comp.
>> procedure division using reqidt.
>> ast-fired.
>>      display "reqidt: " reqidt with conversion
>>      call "sys$wake"
>>          using omitted omitted
>>          giving return-value
>>      end-call
>>
>> 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.

Fine, then each AST can be identified. QIO has a similar
parameter that will be passed to the AST routine.
Time to replace SETIMR with a QIO to read a mailbox.

Thanks!




>> Hm... Maybe time to make a second try using some C helper routines.
> 
> Or that.
> 
> :-)
> 
> Arne