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

[Jan-Erik Söderholm]

Den 2021-09-21 kl. 20:19, skrev Dave Froble:
> On 9/21/2021 9:30 AM, Jan-Erik Söderholm wrote:
>> Den 2021-09-21 kl. 15:22, skrev abrsvc:
>>> On Tuesday, September 21, 2021 at 9:06:18 AM UTC-4, Jan-Erik Söderholm
>>> wrote:
>>>> Den 2021-09-21 kl. 15:00, skrev Arne Vajhøj:
>>>>> On 9/21/2021 3:15 AM, Jan-Erik Söderholm wrote:
>>>>>> Den 2021-09-21 kl. 03:27, skrev Arne Vajhøj:
>>>>>>> On 9/20/2021 6:55 PM, Jan-Erik Söderholm wrote:
>>>>>>>> I have been looking at the Cobol AST example here:
>>>>>>>> http://computer-programming-forum.com/48-cobol/b75d8c5fdd43048e.htm
>>>>>>>>
>>>>>>>> This does work fine as an example. But what are the options to get
>>>>>>>> some data back to the main program (called "x" in the example)
>>>>>>>> from the ast program (called "ast_routine" in the example)?
>>>>>>>>
>>>>>>>> I have tried different versions of global, external and so on, but
>>>>>>>> no luck so far. How to get "x" and "ast_routine" to share some data?
>>>>>>>> Anything similar to an COMMON area in Fortran?
>>>>>>>>
>>>>>>>> The idea is to have an AST routine that will read from a mailbox
>>>>>>>> when
>>>>>>>> something is written to it. My idea was that the read of the mailbox
>>>>>>>> would be using an AST to avoid polling the mailbox.
>>>>>>>>
>>>>>>>> This is to have a command input to detached processes to get them to
>>>>>>>> reload the config, repoen the log file, close and exit and so on.
>>>>>>>>
>>>>>>>> Are there more options if not everything is done in Cobol?
>>>>>>>> We can easily add some C if that helps...
>>>>>>>
>>>>>>> external works for me.
>>>>>>>
>>>>>>> identification division.
>>>>>>> program-id. x.
>>>>>>> environment division.
>>>>>>> data division.
>>>>>>> working-storage section.
>>>>>>> 01 magic-value pic 9(10) display external.
>>>>> ...
>>>>>>> end program x.
>>>>>>> identification division.
>>>>>>> program-id. ast_routine.
>>>>>>> environment division.
>>>>>>> data division.
>>>>>>> working-storage section.
>>>>>>> 01 magic-value pic s9(10) display external.
>>>>> ...
>>>>>>> end program ast_routine.
>>>>>>>
>>>>>>> $ cobol x
>>>>>>> $ link x
>>>>>>> $ run x
>>>>>>> sleeping for 5 seconds
>>>>>>> 000000012C
>>>>>>
>>>>>> Ah, OK! that will be tested. Hm, is this limited to numeric variables?
>>>>>> My test was using a x(3) variable...
>>>>>
>>>>> Try it!
>>>>>
>>>>> Per documentation then external just moves the variable to a PSECT
>>>>> with the same name as the variable to tell the linker to overlay
>>>>> them.
>>>>>
>>>>> I would expect that to work with any data type.
>>>>>
>>>>>> Hm, if this would had been a read-AST on a mailbos instead of a timer,
>>>>>> maybe the ast_routine can just awake the main code and the mailbox
>>>>>> been read in the main code. The ast_routine could set a variable that
>>>>>> just signals the reason fo the wakeup.
>>>>>
>>>>> I don't understand the problem.
>>>>>
>>>>> If you want the main flow to wait until something is in the mailbox,
>>>>> then why not do a blocking read?
>>>>>
>>>>> Arne
>>>>>
>>>> No, sorry... The main code does other things (the regular business
>>>> processing) all the time. I just do not want it to have to poll the
>>>> mailbox with some fixed interval. I expect an AST to be faster also
>>>> with a more "on-demand" response time.
>>>>
>>>> Will do some more testing this evening after regular business hours...
>>>
>>> Can't you just post an asynchronous QIO read to the mailbox with an
>>> AST routine to service the read within the main program?  In this
>>> fashion, the writing to the mailbox will trigger the action.  In this
>>> fashion, the main program will continue to proceed as normal only
>>> getting interrupted when the mailbox read copletes.
>>>
>>
>> Yes, that is my plan. What I had issues with was how to get the data
>> from the mailbox message back from the AST routine to the main code.
>> Since the AST routine has to be a separate PROGAM section. And it
>> cannot be a sub-program within the main code, the POINTER EXTERNAL,
>> to get the address to the AST routine, does not work in that case.
>> At least not if I understood my tests correctly.
>>
>> But I think I understand the basic AST processing as such...
>>
>>
> 
> What Dan wrote is a good method for having the program doing it's thing, 
> with the possibility of an incoming mailbox read firing an AST.
> 
> 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?

We'll see. Also depends on if the Rdb calls are AST-safe. If you can have
Rdb work in the AST routine that will not distureb any Rdb work in the
main code. Have to read up some on that.

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

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.

I have probably not read enough aboit AST and QUI calls yet...