From:	CSBVAX::MRGATE!GRANROTH@IOWASP.SPAN@SMTP 14-MAY-1988 03:36
To:	ARISIA::EVERHART
Subj:	DECnet "master" server


Received: from STAR.STANFORD.EDU by KL.SRI.COM with TCP; Fri 6 May 88 13:59:17-PDT
Received: from IOWASP by STAR.STANFORD.EDU via MAIL-11 with DECnet;
	  Fri, 6 May 88 13:58:12-PDT
Date: Fri 6 May 88 13:58:11-PDT
From: GRANROTH%IOWASP.SPAN@STAR.STANFORD.EDU (Larry Granroth
      319/335-1960)
Subject: DECnet "master" server
To: info-vax@[128.18.10.6]

Our local system manager recently disabled the "0=" or "TASK="
option in DECnet on our 11/780.  Previous to this, I had developed
a number of network client/server systems which used this feature.
For example, I could distribute a client executable program to a
number of users on remote nodes which would handle a user interface
and produce data plots at the user's local node while requesting
reduced data from a central server.  In the client FORTRAN program,
I used an open statement like the following:

	open (	unit	= net,
	1	file	= 'NODE"USER PASSWORD"::"TASK=SERVER.COM"',
	1	status	= 'OLD',
	1	form	= 'UNFORMATTED',
	1	access	= 'SEQUENTIAL')

Which would initiate the execution of the command file indicated after
the "TASK=".  The "USER" account allowed only network access much like
the DECNET default account.  The server command file would execute the
server FORTRAN program which would immediately open a file called
"SYS$NET" similar to the above open statement.  As long as the client
and server conformed to some protocol, they could very effectively pass
information back and forth by writing to and reading from these network
"files".  Unfortunately, now that the "TASK=" feature is disabled, the
only network servers allowed must be assigned a network task number and
be installed by the system manager.  Having to have the system manager
install every server would be a pain in the proverbial to start with,
but the killer is that there is only a limited small number (255?) of
network task numbers available and the system manager doesn't want to
give me more than one or two.  An acceptable solution would be to have
a single network task number point to a "master" command file which
could accept a keyword from the client software and then fire-up the
appropriate server.  Unfortunately, nobody here seems to know how to
implement this.  I can open SYS$NET in the DCL master and accept the
keyword and start a second command file, but I get an access conflict
when the server FORTRAN program tries also to open SYS$NET.  I've tried
opening the network "file" with shared access in both places, but I still
get the same error.  Closing the file in DCL doesn't work because the
network connection is then lost.  I guess the problem is similar to
trying to open a file during the execution of one program then trying
to use the file in a spawned subprocess. (maybe)
 
So here's the question:  Does anyone out there know of a simple way
to implement a "master" network server which would accept key information
from a remote client task and then start up an appropriate server?

(In case it isn't obvious by this point, I'm working with VMS, DCL, DECnet/VMS,
and VAX FORTRAN.)

Please respond directly to me, since I don't usually have the time to
read all of INFO-VAX.

Larry Granroth
Programmer/Analyst
Dept. of Physics and Astronomy
University of Iowa
Iowa City, IA  52242

GRANROTH%IOWASP.SPAN@STAR.STANFORD.EDU