Operating System - OpenVMS
1753916 Members
7648 Online
108810 Solutions
New Discussion юеВ

Re: Lmiting SHOW USER output to a specific user

 
SOLVED
Go to solution
EdgarZamora_1
Respected Contributor

Re: Lmiting SHOW USER output to a specific user

I think what Jon is saying is that he as the space after the JON (i.e. "JON ") but it is getting trimmed.
Walter Miller_1
Valued Contributor

Re: Lmiting SHOW USER output to a specific user

Yes, you are correct Edgar. Tested on V5.5-2 and V7.1 trailing space does not get trimmed and results are as expected. SHOW USER "SYS " does not return user SYSTEM.
Jon Pinkley
Honored Contributor

Re: Lmiting SHOW USER output to a specific user

There seems to be quite a bit of confusion about what I am saying does not work, probably due to the ITRC fonts and formatting.

As the help for SHOW USERS says, all users that that begin with the specified string are displayed. However, I explicitly included a trailing space character within the quoted string "JON ", and in the past this allowed username JON to be displayed without also displaying username JONES.

At some point in the 7.3 to 7.3-2 timeframe, the code that implements SHOW USERS was evidently changed to explicitly "trim" the string provided to it. This makes it impossible to limit the match to a username that begins with the same substring as another user with a longer username.

And as I stated previously, using PIPE and SEARCH is not a good solution. Here is an example of why.

$ pjon = "PIPE SHOW USER JON | SEARCH SYS$PIPE ""JON """
$ pjonf = "PIPE SHOW USER JON/FULL | SEARCH SYS$PIPE ""JON ""/WIN=(0,1)"
$ pjon
JON DELTA 1
JON SIGMA 1 2
$ pjonf
JON DELTA JON 22A001BE VTA8: TNA9:
(Host: 206.157.122.172 Port: 1251)
***************
JON SIGMA JON 2280909C VTA860: TNA860:
(Host: 206.157.122.172 Port: 2240)
***************
JON SIGMA JON_38117 2280AE02 (subprocess of 2280909C)
***************
JON SIGMA JON_51161 2280B603 (subprocess of 2280909C)
JONELD OMEGA JONELD_1 226281CA VTA2498: TNA2495:
$
it depends
Jon Pinkley
Honored Contributor

Re: Lmiting SHOW USER output to a specific user

EdgarZamora's example using rh* got me thinking. It appears that show user is using something like STR$MATCH_WILD. So I tried

$ show user jo%

and that displays only 3 character names that begin with JO. So it still matches JOE and JON, but it is better than matching everything.

I don't remember seeing this wildcard matching documented.

And the matching does not have to occur at the end of the string, for example,

$ show user *q*

only displays usernames that contain at least one "Q".

I still think trimming trailing spaces is a bug.

If the wildcard matching allowed something to match the "end of string", then I could use that, but I didn't stumble on anything that allowed that.

And I had previously tried /EXACT and /SEARCH without satisfying results.

For now, I will use the JO% method.
it depends
Jon Pinkley
Honored Contributor

Re: Lmiting SHOW USER output to a specific user

Evidently, entering a wildcard character changes the behavior of trailing characters.

If you include a wildcard character, then the implicit trailing "*" is removed.

$ sho user jon
OpenVMS User Processes at 9-AUG-2007 20:19:24.94
Total number of users = 2, number of processes = 7

Username Node Interactive Subprocess Batch
JON DELTA 1
JON OMEGA 1
JON SIGMA 1
JONESME OMEGA 4
$ sho user j%n
OpenVMS User Processes at 9-AUG-2007 20:19:29.88
Total number of users = 1, number of processes = 3

Username Node Interactive Subprocess Batch
JON DELTA 1
JON OMEGA 1
JON SIGMA 1
$ sho user j%n*
OpenVMS User Processes at 9-AUG-2007 20:21:20.67
Total number of users = 2, number of processes = 7

Username Node Interactive Subprocess Batch
JON DELTA 1
JON OMEGA 1
JON SIGMA 1
JONESME OMEGA 4
$
it depends
Jess Goodman
Esteemed Contributor
Solution

Re: Lmiting SHOW USER output to a specific user

Ok, here's why I was confused. My first test showed that using a trailing space worked as expected. I did this test on a 7.3-2 system but the users I was SHOWing were on an older VMS system.

I just repeated the test using users on both the local and a remote 7.3-2 system and I see that with those users the ending space makes no difference.

I get the same result when I do the test on a 7.2-2 system. So it is the VMS version running where the target users are that matters, not the version on the system where the SHOW USERS command runs.

$ SAY F$GETSYI("NODENAME")
AX38
$ SAY F$GETSYI("VERSION","AX38")
V7.3-2
$ SAY F$GETSYI("VERSION","AX39")
V7.3-2

$ SHOW USERS CSERVICE
OpenVMS User Processes at 10-AUG-2007 17:10:41
Total number of users = 2, number of processes = 7

Username Node Interactive
CSERVICE AX36 1
CSERVICE AX38 1
CSERVICE2 AX15 1
CSERVICE2 AX23 1
CSERVICE2 AX36 1
CSERVICE2 AX38 1
CSERVICE2 AX39 1

$ SHOW USERS/NOSUB "CSERVICE "
OpenVMS User Processes at 10-AUG-2007 17:10:52
Total number of users = 2, number of processes = 4

Username Node Interactive Subprocess Batch Network Detached
CSERVICE AX36 1
CSERVICE AX38 1
CSERVICE2 AX38 1
CSERVICE2 AX39 1

Note that "CSERVICE2" users shown are on node AX38 and AX39 (V7.3-2)
but CSERVICE2 users on my other nodes (V6.2-1H3 and V7.2-2) are not.
I have one, but it's personal.
Jon Pinkley
Honored Contributor

Re: Lmiting SHOW USER output to a specific user

Jess,

Thanks for that useful piece of info. I am not sure how show gets process info from other nodes, whether via $getjpi or via remote procedure calls to something like cluster_server.

I am tired, but it seems to me that your results indicate that the string is NOT being trimmed early in the processing before resquesting info from other cluster nodes, otherwise we would expect the same behavior from the 7.2.2 and 7.3-2 nodes.

Jon
it depends
Jon Pinkley
Honored Contributor

Re: Lmiting SHOW USER output to a specific user

The mystery is solved, but I will now have to formally request a fix. The change affects any consumer of $PROCESS_SCAN that passes a pattern string with trailing spaces.

There was no change at all to SHOWUSER code, it is the $PROCESS_SCAN system service that was changed. What is disappointing is that the problem fixed by X-22 had been noticed and fixed before in X-10. If we don't learn from history, we are doomed to repeat it. I would have expected this to be flagged by regression testing, but perhaps it was not because there was no QAR reporting that problem; it was caught by the developer's testing.

Jon

-----------------

Sanitized excerpts of comments from the 7.3-2 listings follow.

From [V732.SYS.LIS]PROCESS_SCAN_CHECK.LIS (with listing format removed) and names removed to protect the guilty.

; X-22 ******* **** 10-Jun-2002
; X-19 failed to take into account that there are cases
; were a "space" pattern string can be useful, like when
; using the PSCAN$M_NEQ flag. In this case, leave one
; "space" character for pattern string.

---- unrelated stuff removed ----

; X-19 ******* **** 26-Jul-1999
; Fix the handling of wildcard search operations on
; ACCOUNT and USERNAME fields. This involves removing
; any trailing blanks from the pattern string before
; calling the search routine (EXE$MATCH_NAME). In doing
; so, the special case handling of "spaces in the pattern
; string" has also been rendered unnecessary and so has been
; removed. This also allows future expansion of usernames to
; include embedded spaces. P_ACCOUNT and P_USERNAME have been
; remodeled to use a common configuration routine.
; These changes were reviewed and approved by *** ********
; and **** ******.

But if we look at previous edits,

; X-10 RLP026 *** **** 10-May-1993
; The wildcard match fix (X-9) for username broke the case
; where the user specified a name with trailing blanks in it
; (e.g. the process name as returned by getjpi). So I
; have changed the code to only strip trailing blanks
; from the target string if the specified string
; does not contain any blank characters. (Fixes qar 575
; in the EVMS-EPSILON database).
;
; Also fixed another bug I noticed in testing this - that
; if prefix_match is specified and the test string is too short,
; the code always returns no-match, even if NEQ was also
; specified. It should return match if NEQ was also specified.
;
; X-9 RLP023 *** **** 15-Mar-1993
; Fix bug in wildcard match checking for username.
; (qar 2074 in EVMS-DELTA database.)
it depends