[Info-vax] Stupid question of the day, re: OpenVMS process names

[Dave Froble]

On 3/16/2020 10:21 AM, Tim Lovern wrote:
> On Friday, March 13, 2020 at 7:39:01 AM UTC-7, Stephen Hoffman wrote:
>> On 2020-03-13 13:55:51 +0000, Tim Lovern said:
>>
>>> ...So what is actually happening behind the curtain?
>>
>> Others have answered the immediate question.
>>
>> Pragmatically, process names are best considered nice labels for the
>> SHOW SYSTEM display.
>>
>> Process names are something I'd avoid for most other uses.
>>
>> They're a less-than-entirely-robust means of target identification,
>> when used for process management.
>>
>> I'd avoid them when working within an application.
>>
>> Use another means of identifying the target, such as a lock.
>>
>> I've seen cases of duplicate process names in the same group.
>>
>> Whether that was a race condition, or otherwise?
>>
>> They're best considered semi-useful display artifacts.
>>
>>
>>
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
>
> unfortunately, I cannot avoid having some meaning to them. The
> legacy
code I am supporting uses the process name for certain detached
processes to identify them for message passing. It's actually kind of
clever, in an 80's sort of way.

Actually, no, it is not.  PID is probably the best ID for such.

> A program that needs to receive messages, looks at the process name
> it
it running under, and then constructs all the data structures required
to get messages intended for that process.

I use SYSTEM logicals to identify targets of messages.  Always the same 
logical name.

> Applications needing to send a message, translate a logical that is
constructed using certain rules, and they know who to send to.
>
> At the time, it was probably one of the better approaches to
> run-time
determination of how to do it.
>
> Now, of course, there are many better ways to implement it, but in
> our
case it is probably not worth the time and effort to change it - too
many other fish to fry, so to speak.
>
Probably would not be hard to do ...

I have a utility that stores and forwards messages.  If you want to look 
at it, let me know.  Another piece of code does the message send and 
receive.

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