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

[Arne Vajhøj]

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

Even back then there must have been better alternatives.

But decisions are made. Sometimes there is reason to regret decisions
from the past. It happens.

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

If the intention is to migrate off VMS in a few years then it may
be impossible to justify a redesign.

But if the plan is to stay on VMS for 10-20-30 years, then you really
should have a plan for fixing old technical debt.

Arne