From:	CSBVAX::MRGATE!LEICHTER@Venus.YCC.Yale.Edu@SMTP 17-MAY-1988 15:35
To:	ARISIA::EVERHART
Subj:	re: DECnet "master" server


Received: from Venus.YCC.Yale.Edu by KL.SRI.COM with TCP; Mon 16 May 88 05:59:57-PDT
Date: Sat, 14 May 88 15:04 EST
From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)"
 <LEICHTER@Venus.YCC.Yale.Edu>
Subject: re: DECnet "master" server
To: GRANROTH%IOWASP.SPAN@STAR.STANFORD.EDU, INFO-VAX@KL.SRI.COM
X-VMS-To: IN%"GRANROTH%IOWASP.SPAN@STAR.STANFORD.EDU",INFOVAX

[The original author had been using a variety of servers accessed by the
DECnet "TASK=server" syntax.  Then the TASK object was disabled.  He is
looking for alternatives that avoid (a) the need for the system manager to
intervene to define the objects; (b) without running out of object numbers,
there only being 255 of them.  (c) He suggests a master process that hands
over the network link to an individual server.]

There is no complete solution to what you are trying to accomplish, but there
are bits and pieces that may do the job.

(a) is impossible - that's exactly what disabling the TASK object accomp-
lishes.  One way or another, you are going to have to have cooperation from
your system manager.

(b) is not a problem:  There are only 255 object numbers because they are
intended to represent "well known" generic services.  There can be arbitrarily
many different objects with object number 0.  The TASK object provides a
"generic" extension mechanism, but if you remove it and then use NCP to do,
say:

	SET OBJECT SERVER NUMBER 0

then an access like NODE::"0=SERVER" will work as it always did - although
access to command files that have NOT had object names defined for them will
fail.

Note that the clean, secure way to do this is to have a system-wide logical
defined for the object name that points to a fully-defined (device, directory
specified) command file accessible only from the account the server is
supposed to run in, and then provide a proxy access to that account for those
remote accounts that need to run the server.  For example:

	$ DEFINE/SYS JERRY_SERVER $DISK1:[LEICHTER]SERVER.COM
	$ SET OBJECT JERRY_SERVER NUMBER 0

where SERVER.COM is accessible only to its owner (me), and my remote account
is proxied to my local account.  This prevents others from making up a
JERRY_SERVER.COM file and creating bogus servers.

To do (c) completely generally requires the use of the undocumented NETACP
calls that are used to implement the NETSERVER image.  But you can get much
the same effect in at least two different ways:

	- Write a small program that handles the request by opening SYS$NET,
	  reading the first record, then using that to select an image to run
	  with LIB$FIND_IMAGE_SYMBOL.  Since you never go through image
	  rundown, you can continue to use the file - to talk over the link.

	- Fake the above from DCL:  In DCL do an

	  	$ OPEN/READ/WRITE LINK SYS$NET:

	  LINK is now a logical that refers to a process-permanent file that
	  points to the network link.  It can be used from DCL level - just
	  READ or WRITE LINK - or from a program:  Just do an open on filespec
	  "LINK:".  This can be done any number of times from any number of
	  images run one after another.  An interesting use of this technique
	  is to do:

		$ ASSIGN LINK SYS$OUTPUT

	  Then stuff written to SYS$OUTPUT will go up the link.

	  Do NOT try to access SYS$NET: directly; that will fail, since LINK:
	  will remain open.

	  It's a good idea to do a DCL CLOSE on LINK when you are done with
	  it.  In fact, your DCL code can reject the connection by simply
	  closing LINK.
							-- Jerry