On UNIX, an obsolescent variant of this syntax that specifies a host name allows:
but the UNIX syntax is not portable to other operating systems; its use in new code is discouraged.
For example, to open a file named /usr/bob/foo on a host george, you would use:
(> is shown for the device MODULE separator, $devModBrk; the actual character may differ on some operating systems).
The hostName field is the name by which the desired system is known to the machine on which MAINSAIL is running. The hostPath is the file name in the syntax expected by the host system. The hostPath must be a complete path name, since there is no concept of a current directory on a remote system.
The normal MAINSAIL file I/O routines work as usual. The fact that the file resides on another host is hidden from the user, except for speed of access. Thus, for example, files on remote systems may be edited by the MAINSAIL editor or compiled by the MAINSAIL compiler, and compiler output may be directed to a remote system.
Internally, the NET MODULE reads and writes the file one buffer at a time. Thus it is not necessary to wait for the entire file to be transmitted to read or write it. The remote file never exists in the local file system.
On systems that do not provide operating system file versions, the server that provides access to the system's files prevents more than one user from opening the same file for conflicting purposes through NET. Thus, if two processes attempt to open a UNIX file net(foo)>/usr/bob/bar for writing, the second process gets an error. However, no check for simultaneous local access is made unless the operating system supplies this check as part of its standard file I/O.
SEARCHPATH *.olb *.olb net(central)>/usr/mainsail/*.olb
ENTER graflib net(george)>/usr/george/lib/grafix.olb
SEARCHPATH george:* net(george)>*
This allows files on the node george node to be accessed with the prefix george:.
Before NET can be used, servers must be installed and the services table must be set up. The installation of the remote file system is described in Appendix A.
As currently implemented, there is no notion of security or file protection in NET. Because the server typically runs as root, any file on the remote system can be accessed through NET. Also, the default file protection for files created through NET reflects that of the server process, which may cause problems if the file is later accessed locally on that system by a non-root user.
Each host system imposes some limit on the number of simultaneous open files a process may have. Since all files accessed remotely at a given host are accessed through a single process on that host, the maximum number of remote files open on a given system is limited and may easily be exceeded. For example, the server running on SunOS uses three file handles for stdin, stdout, and stderr, MAINSAIL itself uses one for its system library, the port for accepting clients uses an additional one, and each remotely opened file uses two files (the socket stream and the actual file being accessed). To verify files, $fileInfo is used, which requires at least one additional file. Since a limit as low as 31 files has been imposed on some UNIX systems, only 12 files may be open simultaneously through NET on such systems.
If NET is used to open a non-disk file that blocks for long periods (e.g., a terminal), all clients accessing the same server are blocked.
The check for simultaneous access of files through NET currently uses the $fullPathName field returned by $fileInfo. On some systems, it is possible for the same physical file to have different $fullPathName values (e.g., hard links under UNIX). On such systems, the simultaneous access check done in the server may fail to detect the collision, with possible damage to the file being accessed twice.