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

[Jan-Erik Söderholm]

Den 2021-09-22 kl. 00:22, skrev Arne Vajhøj:
> On 9/21/2021 5:21 PM, Jan-Erik Söderholm wrote:
>> Den 2021-09-21 kl. 20:47, skrev abrsvc:
>>> On Tuesday, September 21, 2021 at 2:22:28 PM UTC-4, Dave Froble wrote:
>>>> Then comes the question of whether the AST would actually perform any
>>>> required actions, or just interrupt the program and have the program
>>>> handle the processing.
>>>>
>>>> Is the required actions simple enough and quick enough to have the AST
>>>> routine perform the work?
>>>>
>>>> For sharing data, what I have not tried, but I'd be tempted, is to
>>>> declare some structure, in Basic it would be a RECORD, and pass the
>>>> address (By Ref) to the AST routine, which also would have an identical
>>>> RECORD definition, such that the two (main and AST routine) can both
>>>> share the data in the structure. All that would be required, I think,
>>>> is some variable that can be passed, By Ref, to the AST routine.
>>>
>>> I agree with Dave, and as long as the data area is only accessed by one
>>> execution stream at a time, it should be OK.  I think that the issue is
>>> whether or not another can interrupt the processing of the first.
>>
>> But if you haven't made a new QUI, there cannot be any new AST, can there?
>>
>>> In this case, as long as the incoming record is processed prior to any
>>> issuance of another QIO, it should be OK.
>>
>> Ah, OK. What I wrote... :-)
>>
>>> You run the risk of filling up the mailbox with records, but from the
>>> initial request, these records should be fairly infrequent.
>>
>> Say, each 2 min. But when they arrive, we want a 1 sec response time
>> on the screen managed by this application. Today this application is
>> looping and polling some data each 1 sec. So it puts a constant load
>> ("backround noice") on the system and on Rdb. Even when the system is
>> idle, Rdb has 10-20 transactions per second, just from the polling.
>> The application is run on 10-20 screens.
>>
>> 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.
> 
> Arne
> 

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.

I kind of like the simplines of mailboxes, in particular since
we got the CREATE/MAILBOX DCL commands. Very simple to setup.

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...

Hm... Maybe time to make a second try using some C helper routines.