How to fix the base priority for a captive account user in VMS

[Sk Noorul Hassan]

Hi all,

There is a captive account in my VMS box. Once he logs in a process is created in his user name. I want to fix the priority of that process to 4.

Please suggest

[Volker Halle · Accepted solution]

Hi,

UAF> MOD username/PRIO=4

will set the base priority of processes created by this user to 4.

Note that OpenVMS applies priority increments based on certain events (like IO completion). You can not disable this feature on a per-user base.

Are you trying to solve a specific problem ?

Volker.

[Sk Noorul Hassan]

Thanks Volker,

The user was running some report, some how it went to cpu hungry mode & resulted in system lock up. But this happened for the first time. is there any way to get rid off. I found the user name in crash dump( SDA>sho process command).
Am I right?

[Joseph Huber_1]

Note the base_prio 4 is default for all users.
So if You want this captive user run at lower priority, put a 3 or 2 for them.

A better solution probably would be to rewrite the captive procedure to force the CPU hungry program to lower priority (submit to batch, then SYNCHRONIZE).

[Jan van den Ende]

Hassan,

"a captive account user" "was running some report"

So, this report is somehow started from a procedure that is activated by some command procedure.
Locate that procedure, and just before starting the malicious report, add

$ SET PROCES/PRIO=0

Now, the report processing will only run when no other process is asking for the CPU.
Usually, the impact on the report processing running time will not be that big, but all other processes WILL notice!

And directly AFTER the reort is finished, reset things by

$ SET PROCES/PRIO=4

Note, that for priority setting HIGHER than specified in SYSUAF the account needs privilege ALTPRI, but LOWER settings and re-setting are always allowed.

hth

Proost.

Have one on me.

jpe

[Volker Halle]

If you are afraid, that this could happen again, you could lower the base priority of this user (even as low as priority 0).

A process looping at priority 4 should not cause the system to lock up. It may be holding some locks and not releasing them, causing other processes to block.

If you have forced a crash - a very good step enabling you to do further offline troubleshooting - you need to first locate the user's process in the dump.

Start with SDA> SHOW SUMM

If you find a process with this username (and it's the only process running under that user), this process should also be in CUR or COM state - if it's CPU-bound, as a looping process would be.

Set context to that process SDA> SET PROC

Check the accumulated CPU time, there should be a high value:

SDA> SHOW PROC/PHD
... Accumulated CPU time 000000E7
...

Next check, whether this process has any busy channels or is holding any locks:

SDA> SHOW PROC/CHAN

... any channel 'busy' ?

SDA> SHOW PROC/LOCK

... is the first lock (or any other lock) shown in Waiting for... ?


Now check the rest of the processes for unusual status (like RWxxx or such).

Report what you've found (maybe attach the SDA output as a .TXT file) and then we'll consider the next step...

Volker.

[Sk Noorul Hassan]

Volker,
Please find the SDA output attached. User name is TELECOMMS.

[Volker Halle]

The TELECOMMS process only has accumulated about 7.8 CPU seconds (0000030C) by the time you've forced this crash, so I doubt that it really was CPU-bound for an extended amount of time. No busy channels, no waiting locks.

What I'm curious about are all those processes in PFW state (Pagefault Wait).

You can find out, how long a process is waiting in it's current wait queue with:

SDA> READ SYS$SYSTEM:SYSDEF

SDA> SET PROC /ID=
SDA> eva ((@exe$gl_abstim_tics)-@(pcb+pcb$l_waitime))

This will give the wait time in 10ms ticks. Try to find a PFW process, which is waiting for a really long time.

What does SDA> EXA EXE$GL_FLAGS report ?

What made you decide to force a crash ? What did you see in the system at that time ? How long did you wait, before you decided to force a crash ?

Crashdump analysis is not trivial. Analyzing a forced crash may be even more complicated. You need to find something, e.g. some 'hanging' operation, from where you start your analysis.

Volker.

[Volker Halle]

Oh, ERRFMT is in LEF - it should normally be in HIB !

Please check whether ERRFMT has any busy channels or waiting locks. Also please check, the waitime for this process.

Does SDA> SHOW DEVICE DI or DK show any non-zero error counts on the disks ?

I guess you do not have the console output available, otherwise this could be helpful as well.

Volker.

[Volker Halle]

... and JOB_CONTROL and QUEUE_MANAGER are in LEF, so we at least haev something to start at...

Possibly anything wrong with the system disk ? Or with the disks containing SYSUAF or queue manager files ?

Volker.