On 2022-09-14 01:14:32 +0000, Arne Vajhj said:

> On 9/13/2022 8:56 PM, Dave Froble wrote:
>>
>> 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.

Doorbell locks are common—albeit when last I checked, the documentation
on the technical was, well, missing—and locks and lock value blocks are
how an app passes around state even in the event of cluster host
failures.

If you want a primary-secondary design or anything similar with a
counter or similar app-local context or related failovers, locks are
how that's done on OpenVMS.

--
Pure Personal Opinion | HoffmanLabs LLC

On 14/09/2022 7:23 am, 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.
>
> -- Rob
>
>

And I believe with Oracle's DLM the LVB can incorporate an entire
database page which forms the infrastructure needed for Cache Fusion.

The rest of us just have to BLAST the holder and ping it to disk unless
you're a single node with global buffers.

Anyway, I'd just like to say well done @Arne an not bitch about "but you
didn't do this". If Arne's put it in GitHub then knock yourselves out.

On 14/09/2022 9:14 am, Arne Vajhøj wrote:
> 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
>
>
>

Example: Trade Matching and Clearing system

Half-trades would come in as they happen.
Supplier process simply cannot be write to an ISAM file quick enough to
keep up.
If Consumer process reads past eof of matching sequential queue file it
will have to close the SEQ file, open it again and re-read the many
thousands of already processed trades to get back up to dat.

Solution: Lock Value Block

The ID of the last txn written is stored in the LVBLK.
When the Consumer obtains the lock and discovers the last txn available
is the same as the last it just processed it goes to sleep and waits for
a BLAST from the producer.

Summary: I call that interprocess communication

On 9/13/2022 9:14 PM, Arne Vajhøj wrote:
> 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.

From that perspective then more on your list aren't what I'd consider easy
communications. Global sections for example are some serious work. Nor would I
stoop to using files or databases for inter-process communications. Sockets and
mailboxes might be what I'd consider "low hanging fruit".

--
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 9:14 PM, Stephen Hoffman wrote:
> 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.
>
>

Not arguing any of that. All I was implying was that both sides of a
communication must insure a successful communication, or, it never happened.

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

Arne Vajhøj formulated on Tuesday :
> 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

Should layered/third party products like RTR, DEC MessageQ or even
MQ Series (and its Opensource equivalents) be mentioned in such a work
too ? Honest open question, not saying that they are missing...

--
Marc Van Dyck

On 2022-09-13, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Not arguing any of that. All I was implying was that both sides of a
> communication must insure a successful communication, or, it never happened.
>

Not that simple (for performance reasons).

Protocols such as TCP, ZMODEM, and Kermit (with sliding windows enabled)
are all asynchronous protocols where the delivery of data to the end user
program is decoupled from the sending of ACKs back to the transmitter.

The receiver end user program can easily have received a good amount of
data from the transmitter before the transmitter has received the ACKs
from the receiver to confirm receipt of that data.

You need something that guarantees the receiver end user program and
the sender end user program are in sync at all times ? You can do that
with a layer on top of the underlying protocol, but you will take a
serious performace hit for doing so.

Simon.

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

On 9/14/2022 1:34 PM, Simon Clubley wrote:
> On 2022-09-13, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Not arguing any of that. All I was implying was that both sides of a
>> communication must insure a successful communication, or, it never happened.
>>
>
> Not that simple (for performance reasons).
>
> Protocols such as TCP, ZMODEM, and Kermit (with sliding windows enabled)
> are all asynchronous protocols where the delivery of data to the end user
> program is decoupled from the sending of ACKs back to the transmitter.
>
> The receiver end user program can easily have received a good amount of
> data from the transmitter before the transmitter has received the ACKs
> from the receiver to confirm receipt of that data.
>
> You need something that guarantees the receiver end user program and
> the sender end user program are in sync at all times ? You can do that
> with a layer on top of the underlying protocol, but you will take a
> serious performace hit for doing so.
>
> Simon.
>

What type of hit might one experience if the customer billing is say $1000 and
the last 2 zeros are chopped off the message?

Not that that is anything real. You cannot convince me that if the
communication was not verified, it is anything but "it never happened".

Accuracy is a great deal more important than performance. Actually, accuracy
isn't everything, it's the ONLY thing.

--
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/14/2022 5:13 AM, Marc Van Dyck wrote:
> Should layered/third party products like RTR, DEC MessageQ or even
> MQ Series (and its Opensource equivalents) be mentioned in such a work
> too ?

ActiveMQ is already there. If I were to add another message queue then
I would probably pick RabbitMQ as I think ActiveMQ/ArtemisMQ and
RabbitMQ are the two big ones today. But RabbitMQ code would be the
same as ActiveMQ code, because STOMP protocol and JMS API would
still be used. On the other side MQSeries/WebSphere MQ/IBM MQ
has a separate API besides the standard protocols/API so it
could be relevant. I just don't have access to the software.

I don't know much about RTR, but I got the impression that
it is way than a message queue - and I would probably
consider it out of scope.

Arne

On 9/14/22 4:24 PM, Arne Vajhøj wrote:
> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>> Should layered/third party products like RTR

> I don't know much about RTR, but I got the impression that
> it is way than a message queue - and I would probably
> consider it out of scope.

I don't know much either but I think you are right. It does distributed
transactions like TransactionScope in .NET will do when more than one
server is involved. It may use some IPC for some of what it does, but
it's not really IPC.

On 9/14/2022 5:24 PM, Arne Vajhøj wrote:
> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>> Should layered/third party products like RTR, DEC MessageQ or even
>> MQ Series (and its Opensource equivalents) be mentioned in such a work
>> too ?
>
> ActiveMQ is already there.

Am I missing something? I thought all those were third party products?

--
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/14/2022 6:30 PM, Dave Froble wrote:
> On 9/14/2022 5:24 PM, Arne Vajhøj wrote:
>> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>>> Should layered/third party products like RTR, DEC MessageQ or even
>>> MQ Series (and its Opensource equivalents) be mentioned in such a work
>>> too ?
>>
>> ActiveMQ is already there.
>
> Am I missing something?  I thought all those were third party products?

I believe RTR is VSI, but DEC MessageQ must be Oracle today, MQSeries
is IBM and ActiveMQ is open source (but VSI does make it available
https://vmssoftware.com/products/activemq/ for Itanium).

But if it is usable from VMS applications then I may
consider it in scope.

Arne

Den 2022-09-15 kl. 00:30, skrev Dave Froble:
> On 9/14/2022 5:24 PM, Arne Vajhøj wrote:
>> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>>> Should layered/third party products like RTR, DEC MessageQ or even
>>> MQ Series (and its Opensource equivalents) be mentioned in such a work
>>> too ?
>>
>> ActiveMQ is already there.
>
> Am I missing something?  I thought all those were third party products?

So what? If they enable IPC on VMS they are of interest, of course.

On 15/09/2022 2:44 pm, Jan-Erik Söderholm wrote:
> Den 2022-09-15 kl. 00:30, skrev Dave Froble:
>> On 9/14/2022 5:24 PM, Arne Vajhøj wrote:
>>> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>>>> Should layered/third party products like RTR, DEC MessageQ or
>>>> even MQ Series (and its Opensource equivalents) be mentioned in
>>>> such a work too ?
>>>
>>> ActiveMQ is already there.
>>
>> Am I missing something? I thought all those were third party
>> products?
>
> So what? If they enable IPC on VMS they are of interest, of course.
>

Not necessarily. Show me VMS/Redis Cache, VMS GitHub, something to load
my VMS Tier3 ASCII files to GitHub

RTR is dead
DMQ is dead
MSMQ is dead
TIBCO is dead
Rendezvous is dead
ESB is dead

*** GraphQL is still born ***

To be brutally honest
VMS is dead

If someone can show me an easy way of getting ASCII fils CR/LF into a
GitHub repository I am happy to do it

Op 14.sep..2022 om 19:40 schreef Dave Froble:
> On 9/14/2022 1:34 PM, Simon Clubley wrote:
>> On 2022-09-13, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> Not arguing any of that.  All I was implying was that both sides of a
>>> communication must insure a successful communication, or, it never
>>> happened.
>>>
>>
>> Not that simple (for performance reasons).
>>
>> Protocols such as TCP, ZMODEM, and Kermit (with sliding windows enabled)
>> are all asynchronous protocols where the delivery of data to the end user
>> program is decoupled from the sending of ACKs back to the transmitter.
>>
>> The receiver end user program can easily have received a good amount of
>> data from the transmitter before the transmitter has received the ACKs
>> from the receiver to confirm receipt of that data.
>>
>> You need something that guarantees the receiver end user program and
>> the sender end user program are in sync at all times ? You can do that
>> with a layer on top of the underlying protocol, but you will take a
>> serious performace hit for doing so.
>>
>> Simon.
>>
>
> What type of hit might one experience if the customer billing is say
> $1000 and the last 2 zeros are chopped off the message?
>
> Not that that is anything real.  You cannot convince me that if the
> communication was not verified, it is anything but "it never happened".
>
> Accuracy is a great deal more important than performance.  Actually,
> accuracy isn't everything, it's the ONLY thing.
>
If accuracy is the only thing, it will be impossible to do a
transaction. In theory it will need an endless series of acknowledging
the acknowledgements. In practice we usually have enough trust in the
underlying communication channels that a one or two level
acknowledgement is sufficient.
There is a trade-of between the needed accuracy and the performance. Not
all communications need the same accuracy. A damaged frame when viewing
a video is a smaller problem than a missing 0 in a bank transfer. So,
the latter will use a more accurate communication protocol. But even
then we accept an error once in a million years, because otherwise
transactions are not possible at all.

On 9/15/2022 2:58 AM, Richard Maher wrote:
> On 15/09/2022 2:44 pm, Jan-Erik Söderholm wrote:
>> Den 2022-09-15 kl. 00:30, skrev Dave Froble:
>>> On 9/14/2022 5:24 PM, Arne Vajhøj wrote:
>>>> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>>>>> Should layered/third party products like RTR, DEC MessageQ or
>>>>> even MQ Series (and its Opensource equivalents) be mentioned in
>>>>> such a work too ?
>>>>
>>>> ActiveMQ is already there.
>>>
>>> Am I missing something? I thought all those were third party
>>> products?
>>
>> So what? If they enable IPC on VMS they are of interest, of course.
>>
>
> Not necessarily. Show me VMS/Redis Cache, VMS GitHub, something to load my VMS
> Tier3 ASCII files to GitHub
>
> RTR is dead
> DMQ is dead
> MSMQ is dead
> TIBCO is dead
> Rendezvous is dead
> ESB is dead
>
>
> *** GraphQL is still born ***
>
> To be brutally honest
> VMS is dead
>
> If someone can show me an easy way of getting ASCII fils CR/LF into a GitHub
> repository I am happy to do it

So Richard, if you don't use it, then it''s dead. Have I got that right?

What about the rest of us?

--
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/15/2022 2:58 AM, Richard Maher wrote:
> On 15/09/2022 2:44 pm, Jan-Erik Söderholm wrote:
>> Den 2022-09-15 kl. 00:30, skrev Dave Froble:
>>> On 9/14/2022 5:24 PM, Arne Vajhøj wrote:
>>>> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>>>>> Should layered/third party products like RTR, DEC MessageQ or
>>>>> even MQ Series (and its Opensource equivalents) be mentioned in
>>>>> such a work too ?
>>>>
>>>> ActiveMQ is already there.
>>>
>>> Am I missing something?  I thought all those were third party
>>> products?
>>
>> So what? If they enable IPC on VMS they are of interest, of course.
>>
>
> Not necessarily. Show me VMS/Redis Cache, VMS GitHub, something to load
> my VMS Tier3 ASCII files to GitHub

Redis should be available:

https://vmssoftware.com/products/redis/

BTW, Redis would fit quite nicely into this article, so I will put that
on the TODO list.

> RTR is dead
> DMQ is dead
> MSMQ is dead
> TIBCO is dead
> Rendezvous is dead
> ESB is dead

> To be brutally honest
> VMS is dead

VMS is still alive. And hopefully will be so for many many
years to come.

RTR is also still alive. Not sure how much usage there is.

DEC MessageQ was bought by BEA I believe and I suspect the
product was effectively EOL'd when Oracle bought BEA.

MSMQ is still alive. Although a lot of Windows shops supposedly
use RabbitMQ today.

TIBCO rendezvous and other ESB products also still exist
even though their importance has declined.

Arne

On 2022-09-15 06:58:17 +0000, Richard Maher said:

> If someone can show me an easy way of getting ASCII fils CR/LF into a
> GitHub repository I am happy to do it

I prefer to convert source files and text files to Stream LF files as
part of kitting a release, and that particular issue goes alway.

Mostly.

Most OpenVMS apps will read Stream LF, but some apps do prefer not to
create that file format by default.

Which means reworking the OpenVMS environment to work around that.

With some of the available source code control tools, it's possible to
convert the sequential file format during check-in, as well as running
a pretty-printer on source files.

It'd be nice if the OpenVMS vGit git client flagged VFC and other
~incompatible file formats or reported and converted those files before
upload, but—not having verified this—I'd tend to assume it does not.

--
Pure Personal Opinion | HoffmanLabs LLC

On 16/09/2022 12:03 am, Dave Froble wrote:
> On 9/15/2022 2:58 AM, Richard Maher wrote:
>> On 15/09/2022 2:44 pm, Jan-Erik Söderholm wrote:
>>> Den 2022-09-15 kl. 00:30, skrev Dave Froble:
>>>> On 9/14/2022 5:24 PM, Arne Vajhøj wrote:
>>>>> On 9/14/2022 5:13 AM, Marc Van Dyck wrote:
>>>>>> Should layered/third party products like RTR, DEC MessageQ
>>>>>> or even MQ Series (and its Opensource equivalents) be
>>>>>> mentioned in such a work too ?
>>>>>
>>>>> ActiveMQ is already there.
>>>>
>>>> Am I missing something? I thought all those were third party
>>>> products?
>>>
>>> So what? If they enable IPC on VMS they are of interest, of
>>> course.
>>>
>>
>> Not necessarily. Show me VMS/Redis Cache, VMS GitHub, something to
>> load my VMS Tier3 ASCII files to GitHub
>>
>> RTR is dead DMQ is dead MSMQ is dead TIBCO is dead Rendezvous is
>> dead ESB is dead
>>
>>
>> *** GraphQL is still born ***
>>
>> To be brutally honest VMS is dead
>>
>> If someone can show me an easy way of getting ASCII fils CR/LF into
>> a GitHub repository I am happy to do it
>
> So Richard, if you don't use it, then it''s dead. Have I got that
> right?
>
> What about the rest of us?
>

David you should really (re)watch the Sixth Sense. You've been (brain)
dead for years :-)

On 16/09/2022 4:35 am, Stephen Hoffman wrote:
> On 2022-09-15 06:58:17 +0000, Richard Maher said:
>
>> If someone can show me an easy way of getting ASCII fils CR/LF into a
>> GitHub repository I am happy to do it
>
> I prefer to convert source files and text files to Stream LF files as
> part of kitting a release, and that particular issue goes alway.
>
> Mostly.
>
> Most OpenVMS apps will read Stream LF, but some apps do prefer not to
> create that file format by default.
>
> Which means reworking the OpenVMS environment to work around that.
>
> With some of the available source code control tools, it's possible to
> convert the sequential file format during check-in, as well as running a
> pretty-printer on source files.
>
> It'd be nice if the OpenVMS vGit git client flagged VFC and other
> ~incompatible file formats or reported and converted those files before
> upload, but—not having verified this—I'd tend to assume it does not.
>
>
>
>

Ok. But what tool (that comes standard on the VMS side) do you use? FTP?

And on the Windows client? Filezilla?

On 2022-09-16 02:29:28 +0000, Richard Maher said:

> On 16/09/2022 4:35 am, Stephen Hoffman wrote:
>> On 2022-09-15 06:58:17 +0000, Richard Maher said:
>>
>>> If someone can show me an easy way of getting ASCII fils CR/LF into a
>>> GitHub repository I am happy to do it
>>
>> I prefer to convert source files and text files to Stream LF files as
>> part of kitting a release, and that particular issue goes alway.
>>
>> Mostly.
>>
>> Most OpenVMS apps will read Stream LF, but some apps do prefer not to
>> create that file format by default.
>>
>> Which means reworking the OpenVMS environment to work around that.
>>
>> With some of the available source code control tools, it's possible to
>> convert the sequential file format during check-in, as well as running
>> a pretty-printer on source files.
>>
>> It'd be nice if the OpenVMS vGit git client flagged VFC and other
>> ~incompatible file formats or reported and converted those files before
>> upload, but—not having verified this—I'd tend to assume it does not.
>>
>>
>
> Ok. But what tool (that comes standard on the VMS side) do you use?

To convert a VFC or other RMS sequential format into RMS sequential
format Stream LF:

$ CONVERT /FDL="RECORD; FORMAT STREAM_LF" from.txt to.txt

I've used a DCL loop with an f$file to detect and convert sequential
files not Stream LF, or similar code in the build or release or kitting
or check-in procedures to convert the file format.

Once converted, most OpenVMS tools will continue to work with the
converted file, and will preserve the Stream LF.

There's also ANALYZE /FDL and CREATE /FDL, depending on local
requirements, and fdl$create() for creating files in OpenVMS apps and
languages that don't do Stream LF well, or the FAB/RAB/XAB slog.

I haven't looked at whether any check-in hooks or format-detection
features are available in vGit, as mentioned earlier.

> FTP?

FTP? FTP gets used grudgingly around here. And is not a tool I'd choose
to use for RMS file format conversions.

> And on the Windows client? Filezilla?

Windows? Best ask somebody else about that.

--
Pure Personal Opinion | HoffmanLabs LLC

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.

Updated with mailboxes and DECnet task-to-task.

Mailboxes

Concept
Demo
Standard IO (C, Fortran, Pascal, Cobol, Basic, Java, Python)

DECnet Task-to-Task

Concept
Demo
RMS (DCL, C, Fortran, Pascal, Cobol, Basic, Python)

SYS$ICC_* and Redis on the TODO list.

Arne

Den 2022-09-19 kl. 01:58, skrev Arne Vajhøj:
> 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.
>
> Updated with mailboxes and DECnet task-to-task.
>
> Mailboxes
>
>     Concept
>     Demo
>     Standard IO (C, Fortran, Pascal, Cobol, Basic, Java, Python)
>
> DECnet Task-to-Task
>
>     Concept
>     Demo
>     RMS (DCL, C, Fortran, Pascal, Cobol, Basic, Python)
>
> SYS$ICC_* and Redis on the TODO list.
>
> Arne
>
>
>

Interesting! Now, what was that link now... :-)

On Mon, 2022-09-19 at 11:28 +0200, Jan-Erik Söderholm wrote:
> Den 2022-09-19 kl. 01:58, skrev Arne Vajhøj:
>
>
> Interesting! Now, what was that link now... :-)

I bookmarked it some time ago:
https://www.vajhoej.dk/arne/articles/vmsipc.html
--
Tactical Nuclear Kittens

On 9/19/2022 2:21 PM, Single Stage to Orbit wrote:
> On Mon, 2022-09-19 at 11:28 +0200, Jan-Erik Söderholm wrote:
>> Den 2022-09-19 kl. 01:58, skrev Arne Vajhøj:
>>
>> Interesting! Now, what was that link now... :-)
>
> I bookmarked it some time ago:
> https://www.vajhoej.dk/arne/articles/vmsipc.html

Yep. Sorry for not include the link.

Arne