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

[Tim Lovern]

On Monday, March 16, 2020 at 10:24:44 AM UTC-7, Dave Froble wrote:
> 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

The PID would not be viable, as there were different options, where multiple readers could exist, and targeting them as a group was based on a subset of the process name. Targeting a specific receiver used the entire process name.  Naming conventions guaranteed uniqueness.  Today I'd implement a pub/sub model with some table driven parameters, but it isn't worth it at the moment. Maybe someday.

The old PAMS / DMQ stuff would have been a good (ok?) solution, but I'm where I am and need to focus on so many other things right now.

thanks for the responses