GRANROTH%IOWASP.SPAN@STAR.STANFORD.EDU (Larry Granroth (05/07/88)
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
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (05/15/88)
[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