I did a little writeup:

https://www.vajhoej.dk/arne/articles/vmsipc.html

Content:

Introduction
Shared Memory
Concept
Demo
System Service (C, Fortran, Pascal)
Memory Mapped File
Concept
Demo
System Service (C, Fortran, Pascal)
Writeable Shareable Image
Concept
Demo
Linker/installer (Fortran, Pascal, C, Basic)
TCP/IP Socket
Concept
Demo
Java API (Java)
C API (C)
Python API (Python, Jython)
Wrapper C API (Fortran, Pascal, Cobol, Basic)
Message Queue
Concept
Demo
JMS API (Java, Jython)
STOMP C library (C)
STOMP Python library (Python)
Wrapper C STOMP library (Fortran, Pascal, Cobol, Basic)
Index Sequential File
Concept
Demo
Language builtin (Pascal, Cobol, Basic, Fortran)
RMS API (C)
VMS Python IndexedFile (Python)
JVM ISAM library (Java, Jython)
SQLite Database
Concept
Demo
C API (C)
Python API (Python, Jython)
JDBC API (Java)
JPA API (Java, Jython)
Wrapper C API (Pascal)

Arne

Arne Vajh??j <arne@vajhoej.dk> wrote:
> I did a little writeup:
> https://www.vajhoej.dk/arne/articles/vmsipc.html
> Content:
> Introduction
> Shared Memory
> Concept
> Demo
> System Service (C, Fortran, Pascal)
> Memory Mapped File
> Concept
> Demo
> System Service (C, Fortran, Pascal)
> Writeable Shareable Image
> Concept
> Demo
> Linker/installer (Fortran, Pascal, C, Basic)
> TCP/IP Socket
> Concept
> Demo
> Java API (Java)
> C API (C)
> Python API (Python, Jython)
> Wrapper C API (Fortran, Pascal, Cobol, Basic)
> Message Queue
> Concept
> Demo
> JMS API (Java, Jython)
> STOMP C library (C)
> STOMP Python library (Python)
> Wrapper C STOMP library (Fortran, Pascal, Cobol, Basic)
> Index Sequential File
> Concept
> Demo
> Language builtin (Pascal, Cobol, Basic, Fortran)
> RMS API (C)
> VMS Python IndexedFile (Python)
> JVM ISAM library (Java, Jython)
> SQLite Database
> Concept
> Demo
> C API (C)
> Python API (Python, Jython)
> JDBC API (Java)
> JPA API (Java, Jython)
> Wrapper C API (Pascal)
> Arne

Thanks so much. That's really terrific. And ditto for your other
articles https://www.vajhoej.dk/arne/articles.html which I hadn't
even been aware of. Maybe you might arrange/aggregate them into one
or more books along the lines of Stallman's just released C tutorial
and reference https://git.savannah.gnu.org/git/c-intro-and-ref.git
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
> I did a little writeup:
>
> https://www.vajhoej.dk/arne/articles/vmsipc.html
>
> Content:
>
> Introduction
> Shared Memory
> Concept
> Demo
> System Service (C, Fortran, Pascal)
> Memory Mapped File
> Concept
> Demo
> System Service (C, Fortran, Pascal)
> Writeable Shareable Image
> Concept
> Demo
> Linker/installer (Fortran, Pascal, C, Basic)
> TCP/IP Socket
> Concept
> Demo
> Java API (Java)
> C API (C)
> Python API (Python, Jython)
> Wrapper C API (Fortran, Pascal, Cobol, Basic)
> Message Queue
> Concept
> Demo
> JMS API (Java, Jython)
> STOMP C library (C)
> STOMP Python library (Python)
> Wrapper C STOMP library (Fortran, Pascal, Cobol, Basic)
> Index Sequential File
> Concept
> Demo
> Language builtin (Pascal, Cobol, Basic, Fortran)
> RMS API (C)
> VMS Python IndexedFile (Python)
> JVM ISAM library (Java, Jython)
> SQLite Database
> Concept
> Demo
> C API (C)
> Python API (Python, Jython)
> JDBC API (Java)
> JPA API (Java, Jython)
> Wrapper C API (Pascal)
>
> Arne

Why no mention of mailboxs ?

--
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 Mon, 2022-09-12 at 23:23 -0400, Dave Froble wrote:
> Why no mention of mailboxs ?

I did wonder about that, too.

--
Tactical Nuclear Kittens

Dave Froble formulated on Tuesday :
> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>> I did a little writeup:
>>
>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>>
>> Content:
>>
>> Introduction
>> Shared Memory
>> Concept
>> Demo
>> System Service (C, Fortran, Pascal)
>> Memory Mapped File
>> Concept
>> Demo
>> System Service (C, Fortran, Pascal)
>> Writeable Shareable Image
>> Concept
>> Demo
>> Linker/installer (Fortran, Pascal, C, Basic)
>> TCP/IP Socket
>> Concept
>> Demo
>> Java API (Java)
>> C API (C)
>> Python API (Python, Jython)
>> Wrapper C API (Fortran, Pascal, Cobol, Basic)
>> Message Queue
>> Concept
>> Demo
>> JMS API (Java, Jython)
>> STOMP C library (C)
>> STOMP Python library (Python)
>> Wrapper C STOMP library (Fortran, Pascal, Cobol, Basic)
>> Index Sequential File
>> Concept
>> Demo
>> Language builtin (Pascal, Cobol, Basic, Fortran)
>> RMS API (C)
>> VMS Python IndexedFile (Python)
>> JVM ISAM library (Java, Jython)
>> SQLite Database
>> Concept
>> Demo
>> C API (C)
>> Python API (Python, Jython)
>> JDBC API (Java)
>> JPA API (Java, Jython)
>> Wrapper C API (Pascal)
>>
>> Arne
>
> Why no mention of mailboxs ?

Was going to ask the same. Simple and efficient, covers many of the
needs. Enough for me to motivate the development of a wrapper allowing
me to use mailboxes from DCL.

--
Marc Van Dyck

On Monday, September 12, 2022 at 6:58:44 PM UTC-4, Arne Vajhøj wrote:
> I did a little writeup:
>
> https://www.vajhoej.dk/arne/articles/vmsipc.html
>
> Content:
>
> Introduction
> Shared Memory
> Concept
> Demo
> System Service (C, Fortran, Pascal)
> Memory Mapped File
> Concept
> Demo
> System Service (C, Fortran, Pascal)
> Writeable Shareable Image
> Concept
> Demo
> Linker/installer (Fortran, Pascal, C, Basic)
> TCP/IP Socket
> Concept
> Demo
> Java API (Java)
> C API (C)
> Python API (Python, Jython)
> Wrapper C API (Fortran, Pascal, Cobol, Basic)
> Message Queue
> Concept
> Demo
> JMS API (Java, Jython)
> STOMP C library (C)
> STOMP Python library (Python)
> Wrapper C STOMP library (Fortran, Pascal, Cobol, Basic)
> Index Sequential File
> Concept
> Demo
> Language builtin (Pascal, Cobol, Basic, Fortran)
> RMS API (C)
> VMS Python IndexedFile (Python)
> JVM ISAM library (Java, Jython)
> SQLite Database
> Concept
> Demo
> C API (C)
> Python API (Python, Jython)
> JDBC API (Java)
> JPA API (Java, Jython)
> Wrapper C API (Pascal)
>
> Arne
Arne,

My compliments. I know all too well how much effort it takes to produce such a compendium.

As has been observed, mailboxes are not included.

DECnet Task-to-Task would also make a useful addition. While DECnet does not include encryption, an omission that I have been quietly outraged by for decades, when tunneled over an encrypted IP tunnel OR used locally, it is quite useful. DECnet logical links are message-based, unlike stream-based TCP sockets, which does simplify programming to an extent.

Both network-based techniques have a significant synchronization advantage over shared memory techniques. When either partner of a TCP socket or a DECnet logical link exits, the corresponding partner is automatically notified, allowing the appropriate steps to be taken. Detecting a failed correspondent is far more complex with shared memory techniques. Network links are also atomic. A message is sent or not, there are no partial messages. Shared memory approaches have the inherent danger that an update may be incomplete, corrupting the shared data structure.

My normal recommendation has been to implement using message-passing techniques, unless one can conclusively demonstrate that the performance increment achieved by shared memory can be justified.

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

On Tue, 2022-09-13 at 10:02 +0200, Marc Van Dyck wrote:
> > Why no mention of mailboxs ?
>
> Was going to ask the same. Simple and efficient, covers many of the
> needs. Enough for me to motivate the development of a wrapper
> allowing me to use mailboxes from DCL.

Back in the early 90s at Portsmouth Uni, we put together a MUD game
using only mailboxes as the chaps running the VAX systems limited us to
only the TMPMBX privileges and a ridiculously small 200 block quota
--
Tactical Nuclear Kittens

On 9/13/22 2:39 AM, Single Stage to Orbit wrote:
> On Mon, 2022-09-12 at 23:23 -0400, Dave Froble wrote:
>> Why no mention of mailboxs ?
>
> I did wonder about that, too.

My first thought was why no ICC. And then I actually looked at the
page, which says:

Some ways of process communication are not covered (yet) including:

mailboxes
sys$icc_* system services

On 9/12/2022 10:23 PM, Dave Froble wrote:
> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>> I did a little writeup:
>>
>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>>
>> Content:
>>
>>     Introduction
>>     Shared Memory
>>         Concept
>>         Demo
>>         System Service (C, Fortran, Pascal)
>>     Memory Mapped File
>>         Concept
>>         Demo
>>         System Service (C, Fortran, Pascal)
>>     Writeable Shareable Image
>>         Concept
>>         Demo
>>         Linker/installer (Fortran, Pascal, C, Basic)
>>     TCP/IP Socket
>>         Concept
>>         Demo
>>         Java API (Java)
>>         C API (C)
>>         Python API (Python, Jython)
>>         Wrapper C API (Fortran, Pascal, Cobol, Basic)
>>     Message Queue
>>         Concept
>>         Demo
>>         JMS API (Java, Jython)
>>         STOMP C library (C)
>>         STOMP Python library (Python)
>>         Wrapper C STOMP library (Fortran, Pascal, Cobol, Basic)
>>     Index Sequential File
>>         Concept
>>         Demo
>>         Language builtin (Pascal, Cobol, Basic, Fortran)
>>         RMS API (C)
>>         VMS Python IndexedFile (Python)
>>         JVM ISAM library (Java, Jython)
>>     SQLite Database
>>         Concept
>>         Demo
>>         C API (C)
>>         Python API (Python, Jython)
>>         JDBC API (Java)
>>         JPA API (Java, Jython)
>>         Wrapper C API (Pascal)
>>
>> Arne
>
> Why no mention of mailboxs ?
>

And event flags and locks?

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

On 2022-09-13, Bob Gezelter <gezelter@rlgsc.com> wrote:
>
> My compliments. I know all too well how much effort it takes to produce such a compendium.
>
> As has been observed, mailboxes are not included.
>
> DECnet Task-to-Task would also make a useful addition. While DECnet does
> not include encryption, an omission that I have been quietly outraged by
> for decades, when tunneled over an encrypted IP tunnel OR used locally, it
> is quite useful. DECnet logical links are message-based, unlike
> stream-based TCP sockets, which does simplify programming to an extent.

However, encryption only protects the data while it is in transit. It does
nothing to stop attacks against the protocol stack in the target server
itself if the client has access to the target server.

>
> Both network-based techniques have a significant synchronization
> advantage over shared memory techniques. When either partner of a TCP
> socket or a DECnet logical link exits, the corresponding partner is
> automatically notified, allowing the appropriate steps to be taken.
> Detecting a failed correspondent is far more complex with shared memory
> techniques. Network links are also atomic. A message is sent or not, there
> are no partial messages. Shared memory approaches have the inherent danger
> that an update may be incomplete, corrupting the shared data structure.
>

The no-partial-message guarantee is only true for stream protocols if you
implement something on top of the stream protocol that guarantees you have
received a full message.

In a stream protocol, just because the transmitter sent 4000 bytes, there's
no guarantee that all 4000 bytes were delivered to the receiver before
some connection interruption occurred.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Tuesday, September 13, 2022 at 1:52:35 PM UTC-4, Simon Clubley wrote:
> On 2022-09-13, Bob Gezelter <geze...@rlgsc.com> wrote:
> >
> > My compliments. I know all too well how much effort it takes to produce such a compendium.
> >
> > As has been observed, mailboxes are not included.
> >
> > DECnet Task-to-Task would also make a useful addition. While DECnet does
> > not include encryption, an omission that I have been quietly outraged by
> > for decades, when tunneled over an encrypted IP tunnel OR used locally, it
> > is quite useful. DECnet logical links are message-based, unlike
> > stream-based TCP sockets, which does simplify programming to an extent.
> However, encryption only protects the data while it is in transit. It does
> nothing to stop attacks against the protocol stack in the target server
> itself if the client has access to the target server.
> >
> > Both network-based techniques have a significant synchronization
> > advantage over shared memory techniques. When either partner of a TCP
> > socket or a DECnet logical link exits, the corresponding partner is
> > automatically notified, allowing the appropriate steps to be taken.
> > Detecting a failed correspondent is far more complex with shared memory
> > techniques. Network links are also atomic. A message is sent or not, there
> > are no partial messages. Shared memory approaches have the inherent danger
> > that an update may be incomplete, corrupting the shared data structure.
> >
> The no-partial-message guarantee is only true for stream protocols if you
> implement something on top of the stream protocol that guarantees you have
> received a full message.
>
> In a stream protocol, just because the transmitter sent 4000 bytes, there's
> no guarantee that all 4000 bytes were delivered to the receiver before
> some connection interruption occurred.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
Simon,

I mentioned message framing, although may phrasing may have been very soft. Of course, when using a stream connection, there is no mapping between QIO on the sender and the receive at the recipient. The only guarantee is that the bytes will be delivered in order. If the connection is severed, the results are "undefined." [If memory serves, Gene Amdahl was credited with that phrasing, which appeared in the IBM Systems/360 Principles of Operation manual.]

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

On 2022-09-13 09:29:19 +0000, Bob Gezelter said:

> As has been observed, mailboxes are not included.
>
> DECnet Task-to-Task would also make a useful addition. While DECnet
> does not include encryption, an omission that I have been quietly
> outraged by for decades, when tunneled over an encrypted IP tunnel OR
> used locally, it is quite useful. DECnet logical links are
> message-based, unlike stream-based TCP sockets, which does simplify
> programming to an extent.
>
> Both network-based techniques have a significant synchronization
> advantage over shared memory techniques. When either partner of a TCP
> socket or a DECnet logical link exits, the corresponding partner is
> automatically notified, allowing the appropriate steps to be taken.
> Detecting a failed correspondent is far more complex with shared memory
> techniques. Network links are also atomic. A message is sent or not,
> there are no partial messages. Shared memory approaches have the
> inherent danger that an update may be incomplete, corrupting the shared
> data structure.
>
> My normal recommendation has been to implement using message-passing
> techniques, unless one can conclusively demonstrate that the
> performance increment achieved by shared memory can be justified.

Network message-passing and shared-file communcations code is usually a
win, as it's common code for either local operations or for local and
remote operations, and it avoids all the "fun" with shared memory cache
coherency. If the performance of shared memory is necessary, it's best
treated as an add-on or an addition to network transfers.

OpenVMS lacks any sort of consistent communications API, with a whole
box of easy-to-make-mistakes some-assembly-required parts including
mailboxes, DECnet and IP, shared memory, DCE RPC and (IIRC) SunRPC, the
ever-popular TLS, intracluster communications services, IRPs and ACPs,
shared files, a couple of different message-passing add-on frameworks
including MQTT, etc.

Missing features here include IP and TLS integration with DCL and with
OpenVMS more generally, and preferably with frameworks intended to deal
with communications including IPv4 and IPv6, DNS, and with UDP, TCP,
QUIC, etc., support for REST, and the rest. Writing this code for
OpenVMS really reminds me of writing assembler. It's absolutely
possible to write this stuff for OpenVMS (including writing that code
in now-compiled VAX assembler), but other platforms abstract all this
for the developer. Which makes this stuff easier and faster to deploy,
and with fewer mistakes.

And preferably with connection security, data encryption, logging, and
authentication—that might not be necessary entirely locally, but I've
seen more than a few of these local YOLO pre-Y2K designs re-used for
remote connections, and where sadness ensued.

I've seen more than a few mistakes made with mailbox and DECnet and IP
communications, too. Mailboxes and DECnet and IP all have a
backpressure design which ~everybody gets wrong when they first
encounter it in production, too. Voice Of Experience: do NOT leave a
session in the debugger and head out to lunch.

And eightcubed has a wealth of source code examples.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/13/2022 12:08 PM, Lee Gleason wrote:
> On 9/12/2022 10:23 PM, Dave Froble wrote:
>> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>>> I did a little writeup:
>>>
>>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>>>
>>> Content:
>>>
>>> Introduction
>>> Shared Memory
>>> Concept
>>> Demo
>>> System Service (C, Fortran, Pascal)
>>> Memory Mapped File
>>> Concept
>>> Demo
>>> System Service (C, Fortran, Pascal)
>>> Writeable Shareable Image
>>> Concept
>>> Demo
>>> Linker/installer (Fortran, Pascal, C, Basic)
>>> TCP/IP Socket
>>> Concept
>>> Demo
>>> Java API (Java)
>>> C API (C)
>>> Python API (Python, Jython)
>>> Wrapper C API (Fortran, Pascal, Cobol, Basic)
>>> Message Queue
>>> Concept
>>> Demo
>>> JMS API (Java, Jython)
>>> STOMP C library (C)
>>> STOMP Python library (Python)
>>> Wrapper C STOMP library (Fortran, Pascal, Cobol, Basic)
>>> Index Sequential File
>>> Concept
>>> Demo
>>> Language builtin (Pascal, Cobol, Basic, Fortran)
>>> RMS API (C)
>>> VMS Python IndexedFile (Python)
>>> JVM ISAM library (Java, Jython)
>>> SQLite Database
>>> Concept
>>> Demo
>>> C API (C)
>>> Python API (Python, Jython)
>>> JDBC API (Java)
>>> JPA API (Java, Jython)
>>> Wrapper C API (Pascal)
>>>
>>> Arne
>>
>> Why no mention of mailboxs ?
>>
>
> And event flags and locks?
>
> --
> Lee K. Gleason N5ZMR
> Control-G Consultants
> lee.gleason@comcast.net
>
>

While some things can be used for simple communications, I'd expect much more
from "communication". But yeah, a simple True/False can be considered
communication.

--
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/13/2022 4:23 PM, Bob Gezelter wrote:
> On Tuesday, September 13, 2022 at 1:52:35 PM UTC-4, Simon Clubley wrote:
>> On 2022-09-13, Bob Gezelter <geze...@rlgsc.com> wrote:
>>>
>>> My compliments. I know all too well how much effort it takes to produce such a compendium.
>>>
>>> As has been observed, mailboxes are not included.
>>>
>>> DECnet Task-to-Task would also make a useful addition. While DECnet does
>>> not include encryption, an omission that I have been quietly outraged by
>>> for decades, when tunneled over an encrypted IP tunnel OR used locally, it
>>> is quite useful. DECnet logical links are message-based, unlike
>>> stream-based TCP sockets, which does simplify programming to an extent.
>> However, encryption only protects the data while it is in transit. It does
>> nothing to stop attacks against the protocol stack in the target server
>> itself if the client has access to the target server.
>>>
>>> Both network-based techniques have a significant synchronization
>>> advantage over shared memory techniques. When either partner of a TCP
>>> socket or a DECnet logical link exits, the corresponding partner is
>>> automatically notified, allowing the appropriate steps to be taken.
>>> Detecting a failed correspondent is far more complex with shared memory
>>> techniques. Network links are also atomic. A message is sent or not, there
>>> are no partial messages. Shared memory approaches have the inherent danger
>>> that an update may be incomplete, corrupting the shared data structure.
>>>
>> The no-partial-message guarantee is only true for stream protocols if you
>> implement something on top of the stream protocol that guarantees you have
>> received a full message.
>>
>> In a stream protocol, just because the transmitter sent 4000 bytes, there's
>> no guarantee that all 4000 bytes were delivered to the receiver before
>> some connection interruption occurred.
>>
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> Simon,
>
> I mentioned message framing, although may phrasing may have been very soft. Of course, when using a stream connection, there is no mapping between QIO on the sender and the receive at the recipient. The only guarantee is that the bytes will be delivered in order. If the connection is severed, the results are "undefined." [If memory serves, Gene Amdahl was credited with that phrasing, which appeared in the IBM Systems/360 Principles of Operation manual.]

That's what "handshakes" are for.

Hey, I want to send some data, 4000 bytes ...
Ok, ready to receive data ...
Send the data, wait for a response ...
Ok, received 4000 bytes ...

Anything else would be considered a failure.

In addition, checksums and such could be included to insure the 4000 bytes sent
is the same 4000 bytes received.

--
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 2022-09-13 20:59:40 +0000, Dave Froble said:

> That's what "handshakes" are for.
>
> Hey, I want to send some data, 4000 bytes ...
> Ok, ready to receive data ...
> Send the data, wait for a response ...
> Ok, received 4000 bytes ...
>
> Anything else would be considered a failure.
>
> In addition, checksums and such could be included to insure the 4000
> bytes sent is the same 4000 bytes received.

4K is ~one (modern) disk block, but yeah.

More common to send 4K with a checksum, or 4K encrypted with a
checksum, and let the receiver figure it out, though. An
application-level TCP-style handshake is closer to what is described is
certainly workable, but the chatter greatly slows things. I'd probably
look at the QUIC handshake, or at a message-passing or transaction
framework, if I needed the extra chatter. DECdtm, or Paxos protocol,
or MQTT, and tracking the transaction state, etc. But more generally
with the use of TCP or QUIC, you will get notification of either a
successful send, partial send, or of a failure to send.

It's up to the app or the transaction manager to determine where the
failure occurred, just as it's up to app-local error processing the
trap shadow on an Alpha to determine where the error occurred, or other
sorts of errors.

Put somewhat differently, it's usually best to design the connection
for speed and simplicity and for the common cause, and to (potentially)
make the error path and error recovery path somewhat more ugly.

PS: The TCP send operation has four potential outcomes: all bytes
transferred, a partial transfer with a need to loop and send more, a
local failure with no transfer, or a connection failure from the remote
side with no data transferred. Handling this usually involves a state
machine.

PPS: one of the more common errors here with TCP and such is assuming a
1-to-1 mapping of writes to reads. TCP and QUIC don't (necessarily)
work that way. One big write can become many smaller reads, for
instance.

PPPS: Depending on the platform, QUIC can have a specific API:
https://developer.apple.com/documentation/network/quic_options — with
that, QUIC can be switched to datagram, for instance. And AFAIK,
OpenVMS TCP/IP Services has UDP, TCP, and SCTP, but lacks QUIC.

PPPPS: having a framework that deals with this makes this whole area
far easier to deal with, and with fewer mistakes, and with fewer
problems with encryption or authentication.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/13/2022 4:52 PM, Dave Froble wrote:
> On 9/13/2022 12:08 PM, Lee Gleason wrote:

>> And event flags and locks?

>
> While some things can be used for simple communications, I'd expect
> much more from "communication". But yeah, a simple True/False can
> be considered communication.
Lock value blocks can pass up to 16 bytes of data, or 64 bytes if using extended lock value blocks.

Shadowing driver is a heavy consumer of locks and lock value blocks.

-- Rob

On 9/13/2022 8:52 AM, Craig A. Berry wrote:
>
> On 9/13/22 2:39 AM, Single Stage to Orbit wrote:
>> On Mon, 2022-09-12 at 23:23 -0400, Dave Froble wrote:
>>> Why no mention of mailboxs ?
>>
>> I did wonder about that, too.
>
> My first thought was why no ICC.  And then I actually looked at the
> page, which says:
>
> Some ways of process communication are not covered (yet) including:
>
>     mailboxes
>     sys$icc_* system services

They will hopefully both show up. But they did not make
it for version 1.0.

I do not have any experience wth sys$icc_* so that will
need a little research.

I have actually started on mailboxes, I encountered some
problems with what I want to do, so it got postponed.

Arne

On 9/13/2022 5:29 AM, Bob Gezelter wrote:
> On Monday, September 12, 2022 at 6:58:44 PM UTC-4, Arne Vajhøj wrote:
>> I did a little writeup:
>>
>> https://www.vajhoej.dk/arne/articles/vmsipc.html

> DECnet Task-to-Task would also make a useful addition.

Agree.

I had forgotten about that one.

It will go on the TODO list.

> My normal recommendation has been to implement using message-passing
> techniques, unless one can conclusively demonstrate that the
> performance increment achieved by shared memory can be justified.
I have always liked message queues.

:-)

Arne

On 9/13/2022 12:08 PM, Lee Gleason wrote:
> On 9/12/2022 10:23 PM, Dave Froble wrote:
>> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>>> I did a little writeup:
>>>
>>> https://www.vajhoej.dk/arne/articles/vmsipc.html

>> Why no mention of mailboxs ?
>
>   And event flags and locks?

To me those are synchronization techniques not communication
techniques - or at least not general communication techniques.

Arne

On 9/13/2022 7:23 PM, Robert A. Brooks wrote:
> On 9/13/2022 4:52 PM, Dave Froble wrote:
>> On 9/13/2022 12:08 PM, Lee Gleason wrote:
>
>>> And event flags and locks?
>
>>
>> While some things can be used for simple communications, I'd expect much more
>> from "communication". But yeah, a simple True/False can
>> be considered communication.
> Lock value blocks can pass up to 16 bytes of data, or 64 bytes if using extended
> lock value blocks.
>
> Shadowing driver is a heavy consumer of locks and lock value blocks.

There are all types of communication requirements. Some simple, some not so
simple. For example:

When I need to tell a detached posting program to process an incoming order,
There are multiple things required in the message.

My utility for such communications passes messages almost 512 bytes in length.
Don't always need that much, but when I do, it's there.

--
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/13/2022 8:38 PM, Arne Vajhøj wrote:
> On 9/13/2022 12:08 PM, Lee Gleason wrote:
>> On 9/12/2022 10:23 PM, Dave Froble wrote:
>>> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>>>> I did a little writeup:
>>>>
>>>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>
>>> Why no mention of mailboxs ?
>>
>> And event flags and locks?
>
> To me those are synchronization techniques not communication
> techniques - or at least not general communication techniques.

As Rob pointed out, one can do a lot with the DLM.

Isn't synchronization itself a form of communication?

--
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/13/2022 6:34 PM, Stephen Hoffman wrote:
> On 2022-09-13 20:59:40 +0000, Dave Froble said:
>
>> That's what "handshakes" are for.
>>
>> Hey, I want to send some data, 4000 bytes ...
>> Ok, ready to receive data ...
>> Send the data, wait for a response ...
>> Ok, received 4000 bytes ...
>>
>> Anything else would be considered a failure.
>>
>> In addition, checksums and such could be included to insure the 4000 bytes
>> sent is the same 4000 bytes received.
>
> 4K is ~one (modern) disk block, but yeah.
>
> More common to send 4K with a checksum, or 4K encrypted with a checksum, and let
> the receiver figure it out, though. An application-level TCP-style handshake is
> closer to what is described is certainly workable, but the chatter greatly slows
> things. I'd probably look at the QUIC handshake, or at a message-passing or
> transaction framework, if I needed the extra chatter. DECdtm, or Paxos
> protocol, or MQTT, and tracking the transaction state, etc. But more generally
> with the use of TCP or QUIC, you will get notification of either a successful
> send, partial send, or of a failure to send.
>
> It's up to the app or the transaction manager to determine where the failure
> occurred, just as it's up to app-local error processing the trap shadow on an
> Alpha to determine where the error occurred, or other sorts of errors.
>
> Put somewhat differently, it's usually best to design the connection for speed
> and simplicity and for the common cause, and to (potentially) make the error
> path and error recovery path somewhat more ugly.
>
> PS: The TCP send operation has four potential outcomes: all bytes transferred, a
> partial transfer with a need to loop and send more, a local failure with no
> transfer, or a connection failure from the remote side with no data transferred.
> Handling this usually involves a state machine.
>
> PPS: one of the more common errors here with TCP and such is assuming a 1-to-1
> mapping of writes to reads. TCP and QUIC don't (necessarily) work that way. One
> big write can become many smaller reads, for instance.
>
> PPPS: Depending on the platform, QUIC can have a specific API:
> https://developer.apple.com/documentation/network/quic_options — with that, QUIC
> can be switched to datagram, for instance. And AFAIK, OpenVMS TCP/IP Services
> has UDP, TCP, and SCTP, but lacks QUIC.
>
> PPPPS: having a framework that deals with this makes this whole area far easier
> to deal with, and with fewer mistakes, and with fewer problems with encryption
> or authentication.
>

Well, yeah, but I learned communications over a serial line ...

--
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/13/2022 8:34 PM, Arne Vajhøj wrote:
> On 9/13/2022 8:52 AM, Craig A. Berry wrote:
>>
>> On 9/13/22 2:39 AM, Single Stage to Orbit wrote:
>>> On Mon, 2022-09-12 at 23:23 -0400, Dave Froble wrote:
>>>> Why no mention of mailboxs ?
>>>
>>> I did wonder about that, too.
>>
>> My first thought was why no ICC. And then I actually looked at the
>> page, which says:
>>
>> Some ways of process communication are not covered (yet) including:
>>
>> mailboxes
>> sys$icc_* system services
>
> They will hopefully both show up. But they did not make
> it for version 1.0.
>
> I do not have any experience wth sys$icc_* so that will
> need a little research.
>
> I have actually started on mailboxes, I encountered some
> problems with what I want to do, so it got postponed.
>
> Arne
>

Ask your questions.

Do you want some examples?

--
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/13/2022 8:56 PM, Dave Froble wrote:
> On 9/13/2022 8:38 PM, Arne Vajhøj wrote:
>> On 9/13/2022 12:08 PM, Lee Gleason wrote:
>>> On 9/12/2022 10:23 PM, Dave Froble wrote:
>>>> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>>>>> I did a little writeup:
>>>>>
>>>>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>>
>>>> Why no mention of mailboxs ?
>>>
>>>    And event flags and locks?
>>
>> To me those are synchronization techniques not communication
>> techniques - or at least not general communication techniques.
>
> As Rob pointed out, one can do a lot with the DLM.
>
> Isn't synchronization itself a form of communication?

Yes.

But not what I would call general communication.

It is not intended to send arbitrary messages - it is
intended to synchronize flows.

Arne

On 2022-09-14 00:59:57 +0000, Dave Froble said:

> Well, yeah, but I learned communications over a serial line ...

I did, too.

With home-grown protocols.

With X/Y/ZMODEM.

With a whole lot of serial wiring hand-soldered together, or later with
pin-insertion, and checked with a breakout box.

With loading code from audio tape cassettes, and I'm not referring to DDS here.

And variously with busted UARTs, or with PIO activity that saturated
the processor, or other such.

With a side-trip through SCADA and PLCs, too many of the now-older PLCs
and controllers having completely demented serial protocols.

Times change.

The newer Ethernet pass-through connectors and crimping tools are
better and faster than non-passthrough crimping, and all vastly faster
and more reliable than drilling 10BASE5 taps.

We're all slinging a whole lot more data than we did back then, too.

And with vastly better tooling and apps and networking protocols available.

--
Pure Personal Opinion | HoffmanLabs LLC