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

[Dave Froble]

On 9/21/2021 5:13 PM, Jan-Erik Söderholm wrote:
> 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.

Thinking some more, slowly, I'm not so sure my idea has any merit.  I'm 
in the habit of doing the least required in an AST routine.  However, 
while I'm not a user of Rdb, I've got to think that regardless if it's 
in an AST routine, it's just code, and should do Ok, with Rdb.  That's a 
question for someone else.

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: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486