set login/interactive question

[Uwe Zessin]

Jan,
Yes! Yes! Yes! It was my first VMS upgrade and I tried to 'be clever'.
It was not a privilege problem - I simply didn't get a 'Username:' prompt,
not even on OPA0:!

I thought I wrote that I had fixed it from another cluster member ;-)

The cluster-wide queue manager was there in V4. I am sure that
SYSMAN came with V5.0, but I skipped to V5.1. Cluster-wide process
services came with V5.2.

I always just set MAXPROCESSCNT (good hint, Wim!) and let AUTOGEN calculate
BALSETCNT. Invalid setting can make a system fail during bootstrap -
at least on VAX.

[Ian Miller.]

$ STARTUP$INTERACTIVE_LOGINS == 1400
creates a global symbol which is evaluated by STARTUP.COM

[Kirk Reindl]

Thanks for all the informative responses; this opened up good discussion.

I have enough to accomplish my task.

Kirk Reindl

[John Eerenberg]

fwiw - a hardcoded $ set log/int=1400 in systartup_vms.com gets reset to 64 later in the boot. A $ set log/int=0 in systartup_vms.com only allows users with oper priv to login until later in the boot. A minimum boot ignores startup$interactive_logins and later in the boot does a $set log/int=8. A $ set log/int=0 as well as defining startup$interactive_logins could aid debugging a system boot (don't know, but it may make my life easier).
OPA0 was fine in all cases.

A piece of advice on BALSETCNT:
If this is a high availabilty cluster, maxprocesscnt needs to be much higher then 1,400 interactive users + system processes + padding (after all, you do want some number of users from a failed node to login and continue on the surviving node, yes?). With a fairly hefty wsmax, balsetcnt will run out of system space (physical memory has almost nothing to do with this limitation); autogen corrects for this, but balsetcnt could be too low for decent system performance. Of course there is VBS, etc. that helps. SYSGEN tuning helps, etc. And on and on . . .

Kirk, I guess you got much more from us then you bargined for?
Enjoy!!!
john

[Uwe Zessin]

Thanks for the update, John. It looks like VMS has evolved in almost every corner - on the other hand: one less challenge left ;-)

I agree: it is amazing what a loosely coupled cluster of brains can accomplish.

[Wim Van den Wyngaert]

I also let autogen calculate all max processcnt related settings.
But I monitor the number of processes, the number of users, balance set slots etc and when it reaches e.g. 90% I get an alarm.

This allows you to investigate why there are that many processes or users. I once had a decwindows user that simply openened a decterm each time he needed a window.

Btw : it is good practice to monitor quotas too.

[Jan van den Ende]

John,

about the WSMAX * BALSETCNT limitation:
(the product must fit within 32 bits minus status bits minus 8 bits for byte-per-page, iirc leaving 20 bits);
I am not absolutely sure and do not have de means to check right now, but I think I remember a bootcamp session where these limitations were mentioned as being addressed (in 7.3-2 or in 8.x).
Maybe some-one at engeneering could prove my memory wrong, or can confirm this and give the true value for the version number?

I DO remember that even 10 years ago it was a real nusance: it was not possible to have dozens of relatively small processes on ONE machine together with a (graphical rendition) process that needed a real LARGE WS.
Only solution then was an extra machine, with a rather rigorously different setup, and a lot of extra managent effort to control what ran where.

Jan

[Jan van den Ende]

--- I found the info about WSMAX * BALSETCNT restriction being lifted:
It is as of V7.3-2

Jan

[Ian Miller.]

restriction lifted due to moveing of various structures futher up in virtual memory (P2 space, PT space etc) so not constrained to fit in 32bit 4Gb VA range any more - hurrah for 64 bit VMS!