🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: mod.computers.vax
Article #3857

DECserver software question (a different one)

#3857
From: sysmgr
Date: Thu, 05 Mar 1987 17:39
72 lines
4049 bytes
Greetings and Felicitations...

In the next few weeks I will be installing a Local Area VAXcluster
which will have an 11/750 as a boot node and six VAXstation IIs as
satellites.  I also have a DECserver 100 (and a DECserver 200 on the
way) which will allow terminal access to the cluster.

Here's the problem.  I want to set up the DECserver so that the
user will say "Connect Cluster".  It is my understanding that the
DECserver will then connect the user to the machine that is least
heavily used at the time.  The problem that I forsee is that the
machine that the DECserver determines is "least heavily used" will
be a VAXstation with two users on it (all our VAXstations have
a two user maximum).  I can't imagine that the DECserver would be
smart enough to avoid this, so it would dump the user to the
VAXstation, which would then, in turn, say "sorry, maximum
number of logins reached" and dump the user back to the DECserver.
Voila.  The user is locked out of the cluster.

I'd be interested in hearing some suggestions as to how to avoid
this problem.  Two ideas we've been knocking around are:

1)  Buying multi-user licenses for all our VAXstations.  The
	problem with this is that our salesperson has informed
	us that multi-user licenses are no longer available for
	VAXstations, because too many people were buying VAX-
	stations with multi-user licenses (thereby, in essence,
	turning it into a MicroVAX with graphics capability) and 
	getting the cheaper VAXstation software licenses (cheaper 
	since the VAXstation is considered a "single user" 
	system).  

2)  Modifying the DECserver software so that it will do one of
	two things.  

	a)  Find the system which is least heavily used.  Compare
		the number of users logged in against the number
		of users allowed.  If they match, then repeat the
		process with next least heavily used system.  The
		problem with this is that, although only two users
		are allowed on a VAXstation, the user sitting at 
		the system keyboard can create multiple processes
		which only count as one against the login limit.

	b)  Implement a "Rotary Dial" program instead of the "least
		heavily used" program being used.  Try to log the
		user into the first VAXstation.  If the login fails,
		try the second, the third, and so forth.  If all
		VAXstations fail, dump the user onto the 11/750.
		This ain't pretty, but it's an option.

I'm not a systems programmer, although I could probably hack the 
DECserver software if I had the source.  Has anybody else out there
done this sort of thing?  Any alternate suggestions?  Please respond
via any way that works.

-----------------------------------------------------------------------
               Christopher D. Russell, Operations Manager
                       Computer Aided Design Lab
                        University of Maryland

Arpa:  RUSSELL@KING.EE.UMD.EDU    Jnet:  RUSSELL@UMCINCOM
       RUSSELL@CINCOM.UMD.EDU     UUCP:  ...!seismo!umcp-cs!eneevax!russell
       RUSSELL@ENEEVAX.UMD.EDU    Mail:  Dept. of Mechanical Engineering
Fone:  (301)454-8886/454-8950            University of Maryland
                                         College Park, MD  20742

        "If growing up were fun, I'd have done it already."

-----------------------------------------------------------------------
------
Technical Details
Message-ID: <8703201738.AA23128@ucbvax.Berkeley.EDU>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!KING.EE.UMD.EDU!sysmgr

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!KING.EE.UMD.EDU!sysmgr
From: sysmgr@KING.EE.UMD.EDU.UUCP
Newsgroups: mod.computers.vax
Subject: DECserver software question (a different one)
Message-ID: <8703201738.AA23128@ucbvax.Berkeley.EDU>
Date: Thu, 5-Mar-87 12:39:00 EST
Article-I.D.: ucbvax.8703201738.AA23128
Posted: Thu Mar  5 12:39:00 1987
Date-Received: Sun, 22-Mar-87 16:54:55 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: "System Manager" <sysmgr@king.ee.umd.edu>
Distribution: world
Organization: The ARPA Internet
Lines: 72
Approved: info-vax@sri-kl.arpa