Showing system processes

[Niall76]

Hi,

I would like to be able to show system processes, but to exclude some from appearing. For example if I wanted to see all processes starting with S I would do this:

SHOW SYSTEM/PROCESS=S*
OpenVMS V7.3 on node xxx 2-OCT-2007 13:07:11.27 Uptime 221 19:10:34
Pid Process Name State Pri I/O CPU Page flts Pages
00000401 SWAPPER HIB 16 0 0 00:01:37.23 0 0
0000040F SECURITY_SERVER HIB 10 1395 0 04:32:00.71 453 412
00029C91 SYMBIONT_3 HIB 6 1834 0 00:00:00.88 502 20

But, I need to exclude certain process from appearing, for example SWAPPER. I have tried the following but it shows nothing at all.

SHOW SYSTEM/PROCESS=S* /NOPROCESS=SWAPPER
OpenVMS V7.3 on node IRSYSU 2-OCT-2007 13:07:11.27 Uptime 221 19:10:34

Does anyone know what the SYNTAX for this is?
Is there a type of exclude option that would remove certain processes from appearing in the list but show all the others?

Any help would be much appreciated.

Thanks,

Niall

[labadie_1 · Accepted solution]

Hello

The lexical function f$context will do that easily.

Just do
$ help lex f$context ex
to see an example

and
$ def/user sys$output a.com
$ help lex f$context ex
followed bu another RETURN
to have a command file ready.
Just modify it a litlle to suit your needs.

[Robert Gezelter]

Niall,

The SHOW SYSTEM command does not have the capabilities you describe. However, as my colleague labadie has previously mentioned, one can use the F$CONTEXT lexical function in a DCL command file to create a superset of SHOW SYSTEM with any degree of elaboration that one desires, limited only by one's imagination and time.

With a symbol substitution, one can even substitute one's own improved SHOW SYSTEM procedure, but I do recommend caution to ensure that all of the options work correctly.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley]

As others have stated, show system does not have the functionality you want.

If you just want a quick and dirty way you can use pipe and search as in the following:

$ pipe show system/process=s* | search/nowin sys$pipe "SWAPPER"/match=nor

Using /match=nor will allow you to filter multiple process names.

When you upgrade to 8.3, you will be able to use some rudimentary wildcarding with search, or you could use awk or perl for filtering the output.

Note well. If you are attempting to filter based on username, this method won't work in the general case. You will need something like the F$context example but useing the USERNAME selection item.

Good luck,

Jon

[Hoff]

The process name is comparatively volatile and fickle construct, and you can see duplicate process names across UIC groups. There was (is?) also a case where it was possible to get duplicate process names within a UIC group.

Cooperative control is often the best approach for tasks that might seem to best involve the process name, though there are mechanisms to connect and monitor processes.

Process monitoring tools include Kronos and cron, and various commercial packages; if you're working in a production environment, this is often the most expedient approach. (That OpenVMS lacks a process scheduling and monitoring subsystem can be a problem.) Some related material on batch scheduling, and some links...

http://64.223.189.234/node/97

I'm making some assumptions around the process name here and what the underlying task might be. Your question is quite good at what you are seeking to do, but I'm not clear on the background of the task; on the task and on why this process name solution was picked.

[Niall76]

Thanks everyone for replying, using lexical functions I got it to skip over process that I didn't want showing.

The reason behind this was just to prevent operators from doing a application shutdown or running tasks on the system while certain processes were still running.

I was only trying to change a function that someone else wrote so I was a bit lost. Still not 100% sure on whats going on, but at least now it works. The last two lines are the important ones.
...
$ CTX = ""
$ T = F$CONTEXT("PROCESS", CTX, "PRCNAM", "''xxxx'*", "EQL")
$ NEXT:
$ PID = F$PID(CTX)
$ IF PID .EQS. "" THEN EXIT
$ IMAGE = F$GETJPI(PID,"PRCNAM")
$ IF IMAGE.EQS."''xxxx'1234" THEN GOTO NEXT
...

Thanks again for your help.

Niall

[Jon Pinkley]

Niall,

Knowing even less about what this command procedure does than you, all I will say is that "IMAGE" would suggest the name to of the program that is running, which in general has no correlation to the process name. It is possible the program is setting its process name to something that starts with 'xxxx', but you may want to be looking at the image that is running as well as the process name. You can limit the process names matched with F$context and then check the image being executed by image = F$GETJPI(pid,"IMAGNAME"). In fact that example is straight from help lexical f$context example.

The point being that it may appear to be working, but it may break if there is more than a single process that has a name starting with 'xxxx'.

If on the other hand you really are intersted in the process name f$getjpi(pid,"PRCNAM"), then I would suggest you use a DCL symbol with a name that suggests what it contains; for example prcnam or process_name, i.e.

$ process_name = f$getjpi(pid,"PRCNAM")

instead of

$ image = f$getjpi(pid,"PRCNAM")

Have fun,

Jon

[Hoff]

>>>The reason behind this was just to prevent operators from doing a application shutdown or running tasks on the system while certain processes were still running.<<<

If these are your applications, or if you have some control over or knowledge of same, tying into the critical applications is a better approach. I've had process name scans go off the rails with regularity. And they usually go off the rails "weird" -- where a critical process isn't spotted, or where a non-critical process is identified as being part of the critical set.

Approaches include applications that defend themselves against shutdown, that log themselves via a central control, that use logical names or lock files or other such. More advanced applications use locks or such to coordinate. (That OpenVMS lacks an API here -- beyond stuff like the class scheduler or generic tools such as the lock manager -- for process control and on-line BACKUP and such is certainly an issue.)

Process names are easy and this is a fast fix, but they're also about as unreliable a process command and control mechanism as exists on OpenVMS. (I had one operator running his own processes under SWAPPER and various such names. And I've seen duplicate process names, and other manner of bug-inducing oddities.)

In my book, process names are in the same basic category as event flags -- inviting, familiar, surprisingly hazardous, and not known for scaling upwards.