Login with a high priority

[Wim Van den Wyngaert]

Sometimes, I encounter looping processes on a node. When I try to login, it takes minutes to complete. Yesterday I had the problem with DDP of DSM and after login, stop/id didn't result in a stop of the process. I had to reboot.

Is there an (undocumented) feature to allow high priority login (t.i. with a process priority of e.g. 16) ? And I don't mean changing the sysuaf prio.

Wim

[Volker Halle]

Wim,

how about AMDS/Availability manager - no login required to stop looping processes or just lower their priority or suspend them.

And force a crash, so you could analyse the reason for the loop ;-)

Volker.

[Wim Van den Wyngaert]

Volker,

Yes it's a solution but :
1) AMDS could not lower the priority because the processes wasn't listening
2) I like to investigate before I crash the system

No, I would like a high pri login.

Wim

[David B Sneddon]

Wim,

Can you modify your priorty in the UAF (to 16) then drop it
manually once you login? The login process starts out with
a higher priority then drops it to the UAF value later in
the login process.
At least this way you should always be able to login in a
reasonable time then investigate the other high priority
process.

Dave

[Kris Clippeleyr]

Wim,

What we use over here is what we call the "noodrem" (emergency break in English).
We define a dedicated LAT service on each node bound to a LAT port.
We then start a detached process (with prio 20) that listens on the LAT port.
Whenever someone tries to connect to the service, the process prompts for a password and if valid lets the user in, and goes into dialogue with her/him, executing whatever DCL command is given.

Using this mechanism we were able to intervene even on systems that had CPU eating (application) processes at prio 15.

Hope this helps,
Kris (aka Qkcl)

[Wim Van den Wyngaert]

David

I thought of that. But what about detached processes that don't execute login.com ?
I also dont't want to be in high prio during login unless I need it.

No. Now you can do username/cli/disk/table/new_pass (help login). I hoped on something like /prio= to be undocumented.

Wim

[Wim Van den Wyngaert]

Very nice Kris. No problem with LATACP only running at 12 ?
Another solution could be that a system parameter indicated the priority of a console login. Of course this would be no solution for work stations.

Wim

[David B Sneddon]

Wim,

Maybe I have misunderstood your problem?
You encounter a need to login because of a looping process.
You attempt an interactive login but it takes too long
because of this looping process.
You want to be able to login quickly to investigate the
looping process.
If you have "special" username for this purpose with a priority
of 16 in the UAF then you will be able to do this.
I don't understand the reference to detached processes and
the use of login.com

Dave

[Willem Grooters]

Elevating base priority in SYSUAF won't help. It's the login process that is started on unsolicited input that needs to get high priority. That constitutes a problem, if I deduct from what I hope recall correctly:
Since a new process is considered to reside in state COMO (outswapped), SWAPPER is involved in creating the process - and SWAPPER runs in prio 16....
Nor would it help much if the runaway process runs on even higher priority. You would face the same problem, if not worse, since SWAPPER wouldn't even be able to swap the process in!

The _only_ solution would be a redesign of the whole login process, bypassing swapper. I don't think THAT is a reasonable solution.

As an alternative, you _could_ think of a (high priority), memory resident listener process you could connect to, that allows you to do the things you need to do (login, for instance).

Willem

[Volker Halle]

Wim,

LOGINOUT is started using a base priority of DEFPRI (SYSGEN parameter) - hardcoded.

You could suppress execution of your LOGIN.COM using /NOCOMMAND (i.e. enter Username: wim/NOCOMMAND) - saving some time.

Or have an 'emergency' account with higher base prio in SYSUAF.

Maybe consider to play with Loginout callouts ?

If AMDS can't reduce the priority of the looping process, then nothing else can. As indicated by STOP/ID failing to stop your looping process as well.

Volker.