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

That is why I suggested a message queue instead of mailboxes,
$QIO(W) and AST's.

Way less options for experiencing "unexpected features".

Arne

On 9/21/2021 9:53 PM, Arne Vajhøj wrote:
> On 9/21/2021 9:46 PM, Dave Froble wrote:
>> On 9/21/2021 5:13 PM, Jan-Erik Söderholm wrote:
>>> 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,
>
> That is why I suggested a message queue instead of mailboxes,
> $QIO(W) and AST's.

You'd still have to check the message periodically. Testing a flag, and
already having the message in a buffer, should be more efficient.

> Way less options for experiencing "unexpected features".
>
> Arne

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

Den 2021-09-22 kl. 03:37, skrev Arne Vajhøj:
> On 9/21/2021 8:31 PM, Jan-Erik Söderholm wrote:
>> Den 2021-09-22 kl. 01:31, skrev Arne Vajhøj:
>>> On 9/21/2021 6:55 PM, Jan-Erik Söderholm wrote:
>>>> 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.
>>>>
>>>> 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...
>>>
>>> I know next to nothing about COBOL, but if COBOL use call by ref as
>>> default like FORTRAN, so that the AST routine expects an address,
>>> then the error makes sense.
>>
>> Right. When calling *from* Cobol you can specify "by ref", "by val"
>> and so on. I have looked but I cannot find anything similar when a
>> Cobol routine is *called*. But yes, it very much looks like that a
>> called Cobol routine expects a "by ref" (pointer) parameter.
>>
>> But the SETIMR docs says that this parameter is sent by value.
>>
>>> And the solution could be to call with
>>> address of reqidt in main code (I don't know how to do that i COBOL
>>> but it must be possible).
>>>
>>
>> Good point... And that solved this issue!
>>
>>
>> 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 reference reqidt    <<==
>>                omitted
>>          giving return-value
>>      end-call
>>
>> Replaced "by value reqidt" with "by reference reqidt".
>> That will pass the address (pointer) to reqidt.
>> Silly not thinking about that...
>>
>> The AST routine just uses the paramater as-is as before
>> an now prints "reqidt: 1234" as expected.
>
> I would probably have preferred to keep the formal
> argument as by val and stuffed the address into an integer
> and passed that. Slightly more complicated but I just
> don't like faking the passing mechanism of a system
> service.
>
> Arne
>

Not that much more complicated, one additional pointer definition:

01 reqidt_addr pointer value reference reqidt.
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_addr
omitted
giving return-value
end-call

This also works. A matter of taste, I guess. :-)

Now, a bigger issue is that I found this in the Rdb docs:

------------------------------------------------------------
15.3 Avoiding Asynchronous System Traps

You should not use asynchronous system trap (AST) service routines in
an application that accesses Oracle Rdb databases. If you do, Oracle
Rdb cannot guarantee the behavior of the application.

Because several Oracle Rdb components use AST service routines and
because an AST cannot be delivered while an AST service routine is
currently executing at the same mode or more privileged mode, using
an AST service routine in an application can prevent the delivery of
an AST in one of the components of Oracle Rdb.
------------------------------------------------------------

I posted a question on the Rdb mailing list regarding ASTs, and got
this from, what I regard as, an trustworthy source:

------------------------------------------------------------
Seems pretty clear. At any access mode the program can be either in
non-AST or AST mode.

As long as you are very well aware of this, make certain that your
AST-mode code does whatever it does, never calls anything related
to Rdb, and then exits, you are probable just fine. Do not do
anything that might block (e.g. potential synchronous IO or similar;
explicitly avoid RMS directly or indirectly).

Best that you studiously avoid anything to do with timers or
$HIBER/$WAKE to make your future life easier.
------------------------------------------------------------

It is very much the general guidelines for any interrupt handling
on any kind of environment (have done PIC microcontroller work before).
In all cases, keep your interrupt (or AST) rooutines as short as
possible and let the main code do the processing...

We'll see. Still under investigation.

On 9/22/2021 3:41 AM, Jan-Erik Söderholm wrote:
> Den 2021-09-22 kl. 03:37, skrev Arne Vajhøj:
>> On 9/21/2021 8:31 PM, Jan-Erik Söderholm wrote:
>>> 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 reference reqidt    <<==
>>>                omitted
>>>          giving return-value
>>>      end-call
>>>
>>> Replaced "by value reqidt" with "by reference reqidt".
>>> That will pass the address (pointer) to reqidt.
>>> Silly not thinking about that...
>>>
>>> The AST routine just uses the paramater as-is as before
>>> an now prints "reqidt: 1234" as expected.
>>
>> I would probably have preferred to keep the formal
>> argument as by val and stuffed the address into an integer
>> and passed that. Slightly more complicated but I just
>> don't like faking the passing mechanism of a system
>> service.
>
> Not that much more complicated, one additional pointer definition:
>
> 01  reqidt_addr         pointer     value reference reqidt.
> 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_addr
>               omitted
>         giving return-value
>     end-call
>
> This also works. A matter of taste, I guess. :-)

Yes. They do the same thing.

It just bother me to see a by reference when the documentation
says by value even though there is a good reason.

Arne

On Wednesday, September 22, 2021 at 3:41:15 AM UTC-4, Jan-Erik Söderholm wrote:
> Den 2021-09-22 kl. 03:37, skrev Arne Vajhøj:
> > On 9/21/2021 8:31 PM, Jan-Erik Söderholm wrote:
> >> Den 2021-09-22 kl. 01:31, skrev Arne Vajhøj:
> >>> On 9/21/2021 6:55 PM, Jan-Erik Söderholm wrote:
> >>>> 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.
> >>>>
> >>>> 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....
> >>>
> >>> I know next to nothing about COBOL, but if COBOL use call by ref as
> >>> default like FORTRAN, so that the AST routine expects an address,
> >>> then the error makes sense.
> >>
> >> Right. When calling *from* Cobol you can specify "by ref", "by val"
> >> and so on. I have looked but I cannot find anything similar when a
> >> Cobol routine is *called*. But yes, it very much looks like that a
> >> called Cobol routine expects a "by ref" (pointer) parameter.
> >>
> >> But the SETIMR docs says that this parameter is sent by value.
> >>
> >>> And the solution could be to call with
> >>> address of reqidt in main code (I don't know how to do that i COBOL
> >>> but it must be possible).
> >>>
> >>
> >> Good point... And that solved this issue!
> >>
> >>
> >> 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 reference reqidt <<==
> >> omitted
> >> giving return-value
> >> end-call
> >>
> >> Replaced "by value reqidt" with "by reference reqidt".
> >> That will pass the address (pointer) to reqidt.
> >> Silly not thinking about that...
> >>
> >> The AST routine just uses the paramater as-is as before
> >> an now prints "reqidt: 1234" as expected.
> >
> > I would probably have preferred to keep the formal
> > argument as by val and stuffed the address into an integer
> > and passed that. Slightly more complicated but I just
> > don't like faking the passing mechanism of a system
> > service.
> >
> > Arne
> >
> Not that much more complicated, one additional pointer definition:
>
> 01 reqidt_addr pointer value reference reqidt.
> 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_addr
> omitted
> giving return-value
> end-call
>
> This also works. A matter of taste, I guess. :-)
>
> Now, a bigger issue is that I found this in the Rdb docs:
>
> ------------------------------------------------------------
> 15.3 Avoiding Asynchronous System Traps
>
> You should not use asynchronous system trap (AST) service routines in
> an application that accesses Oracle Rdb databases. If you do, Oracle
> Rdb cannot guarantee the behavior of the application.
>
> Because several Oracle Rdb components use AST service routines and
> because an AST cannot be delivered while an AST service routine is
> currently executing at the same mode or more privileged mode, using
> an AST service routine in an application can prevent the delivery of
> an AST in one of the components of Oracle Rdb.
> ------------------------------------------------------------
>
> I posted a question on the Rdb mailing list regarding ASTs, and got
> this from, what I regard as, an trustworthy source:
>
> ------------------------------------------------------------
> Seems pretty clear. At any access mode the program can be either in
> non-AST or AST mode.
>
> As long as you are very well aware of this, make certain that your
> AST-mode code does whatever it does, never calls anything related
> to Rdb, and then exits, you are probable just fine. Do not do
> anything that might block (e.g. potential synchronous IO or similar;
> explicitly avoid RMS directly or indirectly).
>
> Best that you studiously avoid anything to do with timers or
> $HIBER/$WAKE to make your future life easier.
> ------------------------------------------------------------
>
> It is very much the general guidelines for any interrupt handling
> on any kind of environment (have done PIC microcontroller work before).
> In all cases, keep your interrupt (or AST) rooutines as short as
> possible and let the main code do the processing...
>
> We'll see. Still under investigation.
Jan-Erik,

Yes, that comment in the Oracle RDB documentation is the point that I was referring to in my DECUS seminar. The solution is to have the main thread read from an interlocked queue.

- Bob Gezelter, http://www.rlgsc.com

On 9/21/2021 9:59 PM, Dave Froble wrote:
> On 9/21/2021 9:53 PM, Arne Vajhøj wrote:
>> On 9/21/2021 9:46 PM, Dave Froble wrote:
>>> On 9/21/2021 5:13 PM, Jan-Erik Söderholm wrote:
>>>> 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,
>>
>> That is why I suggested a message queue instead of mailboxes,
>> $QIO(W) and AST's.
>
> You'd still have to check the message periodically.  Testing a flag, and
> already having the message in a buffer, should be more efficient.

Using a message queue (like IBM MQ or ActiveMQ) will avoid AST's,
avoid $QIO(W) and will avoid mailbox size limits.

But it does not solve the concurrency problem.

I would go for a thread for that.

Arne

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

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

On 2021-09-22 01:46:20 +0000, Dave Froble said:

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

The AST parameter is used for that. This is why I pass around that
context block (data buffer(s), the IOSB, other app-specific data, etc),
and why I requeue the context block to pass around the data.

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

Yes; setting a "cancel in progress" bitlock in the app context for that
processing is the wise way to go here, too. Chasing $cancel requests
around is less than fun.

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, September 23, 2021 at 1:10:24 AM UTC+12, Arne Vajhøj wrote:

> Using a message queue (like IBM MQ or ActiveMQ) will avoid AST's,
> avoid $QIO(W) and will avoid mailbox size limits.
>
> But it does not solve the concurrency problem.

Do you have access to modern languages with async/await functionality?

On 9/22/2021 9:41 PM, Lawrence D’Oliveiro wrote:
> On Thursday, September 23, 2021 at 1:10:24 AM UTC+12, Arne Vajhøj wrote:
>> Using a message queue (like IBM MQ or ActiveMQ) will avoid AST's,
>> avoid $QIO(W) and will avoid mailbox size limits.
>>
>> But it does not solve the concurrency problem.
>
> Do you have access to modern languages with async/await functionality?

CPython 3.8 and Kotlin/JVM runs on VMS Itanium.

But I am not aware of anything for native code on VMS Alpha.

But a good oldfashioned explicit thread may still work.

Arne

On Monday, September 20, 2021 at 6:55:06 PM UTC-4, Jan-Erik Söderholm wrote:
> Hi.
>
> 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?

External should have worked - it applies to a whole 01 'record structure' and can have integers, number, text in any any grouping.

If you have access to a server with DECforms installed - or at least the HELP structure you can find a detailed COBOL + AST example in the files FORMS$EXAMPLE:forms$demo_timer*.COB

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

You received a bunch of answers, mostly over the top - insque and the works..
Sure that allows (and is required) for a solid solution but adds no value here.

Just have the AST routing plunk a command in shared 'external' memory.
Initialize with 'moves spaces'.
Have the main loop test for non-spaces
If found - log, interpret, execute, and set back spaces.
In the AST routine you _might_ want test that the shared command buffer is indeed set to spaces before moving in a new command.

Hope this helps,
Hein

I did this many years ago in MACRO32.

The main program set up two queues:

(a) An empty work queue
(b) A buffer queue primed with some arbitrary number of buffers.

The queues were managed using INSQUE/REMQUE.

Main pulls a buffer from the buffer queue, QIOs the mailbox with AST
routine with queue headers as AST param, then $HIBERs.

On wake it pulls buffer from the work queue and processes it putting the
buffer on the end of the free queue when done. Loop until work is
empty then $HIBER.

The AST routine puts the filled buffer on the end of the work queue,
pulls a buffer from the free queue, QIOs the mailbox, $WAKE, and returns.

Volume was low so didn't have to worry about running out of buffers

The LIB$ routines give you access to the instructions so this should
be possible in COBOL.

On 2021-09-29 09:12:20 +0000, Andrew Commons said:

> I did this many years ago in MACRO32.
> ...
> The queues were managed using INSQUE/REMQUE.

INSQUE and REMQUE are interruptable. Best use equivalent the
interlocked queue operations INSQ*I and REMQ*I. Which are not.

I've used this AST design for SCADA work, and in various other
projects, and it has worked well. I'd use KP Threads now, but ASTs were
then what was.

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, 30 September 2021 at 2:48:15 am UTC+9:30, Stephen Hoffman wrote:
> On 2021-09-29 09:12:20 +0000, Andrew Commons said:

> INSQUE and REMQUE are interruptable. Best use equivalent the
> interlocked queue operations INSQ*I and REMQ*I. Which are not.
>
The distinction between the instructions is the type of queue they handle.

From the manual:

"Both INSQUE and REMQUE are implemented as noninterruptible instructions."

On 2021-09-30 01:01:44 +0000, Andrew Commons said:

> On Thursday, 30 September 2021 at 2:48:15 am UTC+9:30, Stephen Hoffman wrote:
>> On 2021-09-29 09:12:20 +0000, Andrew Commons said:
>
>> INSQUE and REMQUE are interruptable. Best use equivalent the
>> interlocked queue operations INSQ*I and REMQ*I. Which are not.
>>
> The distinction between the instructions is the type of queue they handle.
>
> From the manual:
>
> "Both INSQUE and REMQUE are implemented as noninterruptible instructions."

Yeah, you're right. INSQUE and REMQUE are non-interruptible within the
context of a single processor. But they're concurrent within the
context of a multiprocessor. And with no visibility within the
multiprocessor memory caching. Which in aggregate leads to some
hard-to-debug surprises.

See chapters 5 and 6 for a start:
https://vmssoftware.com/docs/VSI_PROGRAM_CONCEPTS_VOL_I.pdf

Also scrounge up a copy of EL-00032-00 DEC Standard 32, and see section
3.8 (page 3-95ff) and chapter 7 (e.g. section 7.1.4, using interlocks
to prevent the corruption of shared data ):

http://www.bitsavers.org/pdf/dec/vax/archSpec/EL-00032-00-decStd32_Jan90.pdf

If your app code stays strictly on one processor and forever avoids
concurrent access to the structures within an SMP system, you can get
away with INSQUE and REMQUE.

Just as soon as the queue becomes shared across processors (KP threads,
multiprocessing), not so much.

I've chased enough of these sync bugs over the years that I'll usually
avoid REMQUE and INSQUE in preference for using INSQHI, INSQTI, REMQHI,
REMQTI, etc.

Another advantage of using INSQHI, INSQTI, REMQHI, REMQTI, etc, is
relative addressing, which means any process or global sections
involved can be mapped at different address ranges in different
processes. Which is really handy.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/29/2021 9:51 PM, Stephen Hoffman wrote:
> On 2021-09-30 01:01:44 +0000, Andrew Commons said:
>
>> On Thursday, 30 September 2021 at 2:48:15 am UTC+9:30, Stephen Hoffman
>> wrote:
>>> On 2021-09-29 09:12:20 +0000, Andrew Commons said:
>>
>>> INSQUE and REMQUE are interruptable. Best use equivalent the
>>> interlocked queue operations INSQ*I and REMQ*I. Which are not.
>>>
>> The distinction between the instructions is the type of queue they
>> handle.
>>
>> From the manual:
>>
>> "Both INSQUE and REMQUE are implemented as noninterruptible
>> instructions."
>
> Yeah, you're right. INSQUE and REMQUE are non-interruptible within the
> context of a single processor. But they're concurrent within the context
> of a multiprocessor. And with no visibility within the multiprocessor
> memory caching. Which in aggregate leads to some hard-to-debug surprises.

Yeah, multi-processors, and multi-cores, really changes the game. Some
concepts from the single CPU era just don't work too well anymore.

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

On 9/29/2021 8:01 PM, Andrew Commons wrote:
> On Thursday, 30 September 2021 at 2:48:15 am UTC+9:30, Stephen Hoffman wrote:
>> On 2021-09-29 09:12:20 +0000, Andrew Commons said:
>
>> INSQUE and REMQUE are interruptable. Best use equivalent the
>> interlocked queue operations INSQ*I and REMQ*I. Which are not.
>>
> The distinction between the instructions is the type of queue they handle.
>
> From the manual:
>
> "Both INSQUE and REMQUE are implemented as noninterruptible instructions."
>

Perhaps he didn't mean non-interruptible - he meant that INSQUE and
REMQUE are not multiprocessor safe, and INSQ*I and REMQ*I are. BY
multiprocessor safe, I mean they can be used in a multiprocessor
environment without additional means of synchronization of access.

--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason@comcast.net