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

[Jan-Erik Söderholm]

Den 2021-09-21 kl. 20:47, skrev abrsvc:
> On Tuesday, September 21, 2021 at 2:22:28 PM UTC-4, Dave Froble wrote:
>> 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?
>>
>> 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.
>> -- 
>> 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
> 
> 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.