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

[Dave Froble]

On 9/22/2021 9:22 AM, Bob Gezelter wrote:
> On Tuesday, September 21, 2021 at 9:48:49 PM UTC-4, Dave Froble wrote:
> (Omitted for the sake of brevity)
>
>> However, I'm not sure you'd have anything to do in the AST routine,
>> since I'm assuming you're going to queue up an async read from the main
>> program, and then continue with whatever the main program is doing.
>> When the AST fires, it lets you know that the read completed, in some
>> fashion, and now the message is in whatever buffer in the main program.
>> I'd assume some flag is set, bu the AST routine, and periodically the
>> main program tests the flag, and processes the message, at that time.
>>
>> Which brings up this question. How many mailboxes are you using? A
>> single mailbox? Or multiple mailboxes (that's a real headache).
>>>> 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 have not read up that much yet to see if there is any other information
>>> you can pass, besides of the address to the AST routine.
>> You mentioned elsewhere that you're unaware of how to define the
>> datatype of an incoming argument. I've done this in Basic. Then the
>> AST routine just uses the labels in the structure definition. The
>> address is the address of the first variable defined in the structure.
>>> But my guess is that, if you queue QIOs from multiple sources, the AST
>>> routine must have some way to tell which source it was that trigged
>>> the AST. Say you make (made up example, not part of our current target)
>>> 10 QIO calls having the address of the same AST routine in the calls,
>>> each QIO reading from its own TNA device, you need to know in the AST
>>> routine which TNA device (like 10 different production machines) it
>>> was that sent something.
>> That sounds like a real headache. Perhaps event flags would help. I
>> tend to avoid event flags.
>>> I have probably not read enough aboit AST and QUI calls yet...
>> ASTs can be fun. I try to use them to set flags or cancel I/O.
>> Cancelling an I/O causes a completion of an async read. I feel that if
>> I try to get "tricky", I'll outsmart myself, not so hard to do with dumb
>> Dave.
>>
>> :-)
>> --
>> David Froble Tel: 724-529-0450
>> Dave Froble Enterprises, Inc. E-Mail: da... at tsoft-inc.com
>> DFE Ultralights, Inc.
>> 170 Grimplin Road
>> Vanderbilt, PA 15486
> Dave.
>
> Distinguishing between multiple sources using the same AST routine is straightforward. OpenVMS nee VAX/VMS QIO has a parameter referred to as ASTPARM (ASTPARM was added to the QIO interface with VAX/VMS; the RSX-11 family QIO did not have ASTPARM).
>
> ASTPARM is an untyped longword. It can be:
> - a buffer pointer (where the buffer structure includes a pointer to an owning data structure)
> - a pointer to a data structure
> - an index into a table of pointers
>
> I have done code which had hundreds (or more) active IO connections active simultaneously using this technique with absolutely no problems.
>
> Straightforward to say the least.
>
> - Bob Gezelter, http://www.rlgsc.com
>

I was looking at that argument in the docs just last night.  I was 
figuring that while the docs declared the argument read only, if it was 
the address of some data, the AST could access and modify the data, 
assuming it was aware of the size of the data.  Then I thought a bit 
more about that "aware of the size of the data" and suffered a few shakes.

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