PRM by PID or app argument?

[John J Read]

On my 6way rp8420 partition, most of the system load is coming from many instances of the same application running under the same userid and same executable. As you can see below, the unique identifiers for each instance are only PID and the second argument of the app. (52141! in the first example)

omnitest 18355 18350 0 Nov 13 ? 06:33 /opt/se/cobol/rts32.0619 DDHSTDRV 52141!
omnitest 19124 19109 0 Nov 13 ? 04:27 /opt/se/cobol/rts32.0619 DDHSTDRV 22141!
omnitest 22319 22314 0 Nov 13 ? 03:43 /opt/se/cobol/rts32.0619 DDHSTDRV 12110!
omnitest 24564 23085 0 Nov 13 ? 03:43 /opt/se/cobol/rts32.0619 DDHSTDRV 12120!


Is it possible to conifgure PRM to separate these out into separate groups? I have tried using the "alternate names" in the application setup in prm. Something like *52141* but that doesn't seem to place the processes in the group.

So, my general question is: Can PRM be configured ad-hoc to isolate processes by PID to you grant CPU minimums to specific running PID?

If not, does anyone know how to isolate the applications listed above into different groups?

[Dan Herington]

Hi John,

The simplest way to get PRM to place any arbitrary set of processes in the right group is to use the startup command/script. If it doesn't already have a startup script, create one - even if it is only 1 line. Then you can either put the startup script in the app manager config or you can simply do a prmrun of the app in the script. If you are using the app manager, you need to consider that the app manager wakes up every 30 seconds looking for new processes - make sure your startup script stays up for at least a minute or so, just to be sure the app manager sees it.

This also helps if there are a number of processes started when the app comes up. All of them will get swept into the correct group together with just the one app record.

Also, because this is a script, you will need to use the alternate name field for the name of the script and the shell will be the binary that is running.