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

[Dave Froble]

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

Haven't done any ASTs for a while, and too lazy to lookup the doc.

But, from memory, you're passing a VALUE, when maybe an address (By Ref) 
is expected.  So when accessing that "location" (reqidt) you're 
accessing a memory location you really should not.  Or maybe I don't 
understand ...

>               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

Yeah, that's the problem, I think.  I haven't looked at Cobol since 
forever ....

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

Right!  You passed a value as the address of the data.  Bad, bad Jan-Erik.

:-)

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


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486