Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

OpenVMS bug with duplicate process names?

 
Mark_Corcoran
Frequent Advisor

OpenVMS bug with duplicate process names?

One of our recent 2nd-line hires asked me why he was getting a couple of errors when he logged in.

 

The first was:

%SET-E-NOTSET, error modifying process name
-SYSTEM-F-DUPLNAM, duplicate name

 

The second was:

%PURGE-W-FILNOTPUR, error deleting USER$DISK:[userdir]NETSERVER.LOG;6094
-RMS-E-FLK, file currently locked by another user
 
Although each 2nd line user has their own account, their SYS$LOGIN and LGICMD are the same, because they perform the same functions.
 
The first problem was due to an explicit SET PROCESS /NAME="Operator" in the LGICMD - "obviously", once a process in the same UIC group already has a process name, you can't have another process with the same name.
 
The second problem is an explicit PURGE /KEEP=5 SYS$LOGIN:*.* trying to purge NETSERVER.LOG files which are being created by FAL SERVER processes as a result of inter-nodal file actions taking place from the partner system when various jobs are scheduled on it by the application (either to compare things between the two nodes, or so that if the master state changes, the other node has a copy of the latest input files used by some command procedures, to avoid them unnecessarily re-reporting things we already know about).
 
I've dealt with the PURGE (well, RMS) error by wrapping the PURGE in a SET MESSAGE /NOFACILITY /NOSEVERITY /NOID /NOTEXT and then a non-negated form of the command.
 
As for the first issue, I wrote some code to generate a unique process name with a fixed prefix, part of the username, and then a unique ID number suffix, looping through processes with F$CONTEXT to see whether or not they existed before attempting to do a SET PROCESS /NAME
 
This was all fine & good until I decided to put some comments in the code to explain what would happen under an abnormal circumstance (if the length of the prefix and the suffix meant that no characters from the username could be used as part of the process name - which would have to mean that there were 1 billion processes running on the system).

So, I tested to see what happened - first login (with no attendant SET PROCESS /NAME in any login procedure) causes the process name to be set to the username,
 
Second login causes the process name to be set to the terminal name (in the testing I was doing, it was "_RTA4:" - when we log in via Telnet, users are automatically SET HOST /LOG=dev:[dir]file.typ back onto the node, to maintain a (poor man's) session log).

That set me thinking...

In one session I logged on with terminal RTA4:
I logged in on another session with terminal RTA5:
I logged out the session with RTA4:
In the session with terminal RTA5:, I did SET PROCESS /NAME="_RTA4:"
I logged in another session, getting terminal RTA4:
The new (second) RTA4: terminal session was also given a process name of "_RTA4:", and a SHOW SYSTEM listed two processes with a process name of "_RTA4:" (both logged in under the same account, and hence, the same UIC group).
 
If you try to SET PROCESS /NAME="same as another process", you get the aforementioned DUPLNAM failure.
 
However, in my testing above, this shows that (I'm guessing) SYS$SYSTEM:LOGINOUT.EXE is not preventing creation of a process with the same name as an existing process in the same UIC group.
 
Obviously, the testing I am doing is pretty perverse, and "unlikely" to occur in the real world - I would imagine that LOGINOUT is (for performance reasons) not running down the list of processes to see whether or not there is another process in the same UIC group with a process name of the terminal device that has been allocated to the process.
 
I can't now remember what the soft-copy manual was that I was looking in earlier, which (IIRC) indicated that process creation disallows creation of a process with a duplicate name, rather than it just being a sanity checking function of SET PROCESS /NAME
 
It's not (for us) a big deal, because this is unlikely to occur in real world situations, but what (if anything) might be the impact of having two processes with the same process name in the same UIC group?

The only thing I can think of is that attempts to reference a process by name would likely get the process with the lower IPID, so you could end up monitoring/killing the wrong process;  I'm not sure whether or not internally it might cause issues for OpenVMS (or some layered products)???
 
For what it's worth, this is OpenVMS/VAX v6.2 under CharonVAX - not sure if the problem persists in other somewhat more recent versions of OpenVMS...
 
[On an unrelated note, I hope to post an update on my BACKUP & EXQUOTA discussion in the next week;  I haven't forgotten about it - I've been working on it almost non-stop when I wasn't off on leave for a week]
 
 
Mark
[Formerly appearing as woeisme]
9 REPLIES 9
Volker Halle
Honored Contributor

Re: OpenVMS bug with duplicate process names?

Mark,

FWIW, on OpenVMS Alpha V8.3 LOGINOUT assigns an empty process name ("") to such a process, if the default process name (_ccann:) already exists, so the behaviour of LOGINOUT seems to have changed.

Volker.

H.Becker
Honored Contributor

Re: OpenVMS bug with duplicate process names?

Hmm, what changed when and where ?

$ sh sys/full/noproc
OpenVMS V8.4-2L2  on node EISNER   15-JUN-2018 03:25:18.96   Uptime  63 08:59:12
        AlphaServer DS20 500 MHz
$ pipe show sys|search sys$pipe rta    
0002620D _RTA1:          LEF      5     1215   0 00:00:00.19       850     86   
00031215 _RTA2:          LEF      4      323   0 00:00:00.18       647     84   
00030A18 _RTA2:          LEF      4      339   0 00:00:00.11       520    103   
$ 
Volker Halle
Honored Contributor

Re: OpenVMS bug with duplicate process names?

 

CHAALP $ sho us/node/full system/int
      OpenVMS User Processes at 15-JUN-2018 09:58:35.02
    Total number of users = 1,  number of processes = 3

 Username Process Name    PID     Terminal
 SYSTEM                        000044BA  VTA83:   TNA84:
 SYSTEM   SYSTEM        000044B0  VTA80:   TNA81:
 SYSTEM   _VTA83:         000044B7  VTA81:   TNA82:

CHAALP $ sho sys
OpenVMS V8.3  on node CHAALP  15-JUN-2018 09:58:24.33  Uptime  372 22:21:07
  Pid    Process Name    State  Pri      I/O       CPU       Page flts  Pages

000044B0 SYSTEM          LEF      4      281   0 00:00:00.49       312    122
000044B7 _VTA83:           LEF      4      191   0 00:00:00.62       442    117
000044BA                       CUR      4      204   0 00:00:00.62       400    185

 

Volker.

H.Becker
Honored Contributor

Re: OpenVMS bug with duplicate process names?

 

More hmmmm, either LOGINOUT changed again or it isn't LOGINOUT. And, would "your" LOGINOUT assign another empty process name if the default process name already exists? Anyway, it seems that on current versions of VMS the system can end up with two (or more) identical process names.

$ sh sys/noproc/full
OpenVMS V8.4-2L2  on node EISNER   15-JUN-2018 05:03:45.64   Uptime  63 10:37:38
        AlphaServer DS20 500 MHz
$ pipe sh sys |search sys$pipe _VTA323
00031031 _VTA3230:       LEF      4      411   0 00:00:00.22       858     63   
00031445 _VTA3230:       LEF      4      563   0 00:00:00.19       693     91   
$

 

Re: OpenVMS bug with duplicate process names?

"but what (if anything) might be the impact of having two processes with the same process name in the same UIC group?" The impact is that trying to manage the process by name may be indeterminate. You can always manage the process by PID. VMS has always had a "feature" that you can get duplicate process names within a group by having your UIC outside of the group, changing your process name to a duplicate, and then changing your UIC to be within the group. Changing your UIC does not revalidate the process name.
abrsvc
Respected Contributor

Re: OpenVMS bug with duplicate process names?

Are you sure that the process names are exactly equivalent?  I would look for invisible characters (spaces).  The space is a significant character unseen in a name display.

Dan

H.Becker
Honored Contributor

Re: OpenVMS bug with duplicate process names?

Did you look? How?

$ pipe sh sys |search sys$pipe "_VTA3417:"
00031E30 _VTA3417:       LEF      8      640   0 00:00:00.56       996    166   
00030634 _VTA3417:       LEF      5      815   0 00:00:00.16       616    111   
$ write sys$output "<"+f$getjpi("00031E30","prcnam")+">"
<_VTA3417:>
$ write sys$output "<"+f$getjpi("00030634","prcnam")+">"
<_VTA3417:>
$ 

Do you suspect that $getjpi trims/suppresses invisible characters?

Mark_Corcoran
Frequent Advisor

Re: OpenVMS bug with duplicate process names?

Thanks to all who replied;  following on from Volker & Hartmut's posts, I considered briefly that it might be an artefact of the terminal driver, so that perhaps the VT driver had been updated but the RT one had not;  then I came to my senses and thought it wouldn't make programmatic sense for the process name to be set by the terminal driver.

 

Chris - your point about UIC changing - yes, very valid - I hadn't even considered it, though in this particular case, checking for duplication at process creation is something that could be done, and arguably should be done.

 

Dan - re the process names having additional spaces (and which might have been a means by which differentiation between processes could have been made)- I hadn't considered that, but Hartmut's post suggests that that's not the case.

 

It's not something that we (or, I suspect) most folks are likely to encounter in the real world, so I'm not going to worry too much about it - it's just an oddity that I encountered when positing a "what if..." and wanted to make sure I wasn't going nuts.

 

Mark

[Formerly appearing as woeisme]
abrsvc
Respected Contributor

Re: OpenVMS bug with duplicate process names?

FWIW, I have seen process names that appear to be the same with trailing spaces.  While using the F$getjpi service as shown earlier will show trailing spaces in the count, the original posting did not use that to show the process names.  With the standard services (show system for example), the trailing spaces will not be seen and thus could be the difference in process names.

Dan