Alastair Milne This is a description of the configuration now being used for the PC- NFS local area network of the Educational Technology Center. It also describes the programming environments using the net. For detailed information on PC-NFS itself, consult the user's manual from Sun.
From the ETC/ICS trailer, the cable connects with the Sun computer called "madeleine", located in the ICS Student Counselling trailer, next to ours. The section of the network in the ETC trailer is a logical "subnet" of the ICS department network. "madeleine" is its gateway to the rest of the ICS network, giving the impression of immediate access to dozens of ICS (and some Computing Facility) machines.
Subnetting means that network traffic between hosts on the subnet need never leave it and burden the ICS backbone. (This at lesat is the theory, though the extent of its practical effect would have to be verified by support).
The logical arrangement of Ethernet makes each NFS UNIX host equally accessible to all its neighbours: no one UNIX machine is more or less visible than any other. Among the micro's running PC-NFS, though, the situation is more limited: see below under "shared file space". The physical arrangement, however, leads a single length of cable from each machine to the next. A most important consequence is that there is a final machine on the cable, after which the cable must have a terminator.
** EXTREMELY IMPORTANT **:
Since the ETC lab is (at this writing) the final site along this
branch of the cable, a cable terminator caps the "T" connector on
the final machine in the net (where, on the preceding machines, the
cable to the next machine is attached).
This terminator *MUST NEVER BE MOVED* from the end of the cable
without the express permission of Network Services; nor must *ANY
PART* of the cable be disconnected from its successor, since that
would isolate the terminator from the rest of the cable.
**DOING SO WILL CRASH AT LEAST THE ENTIRE SUBNET AFTER 5 SECONDS!**
When the system first boots to DOS, it starts the net first. You will see at least the following happen:
C:\>NFSRUN
C:\>NET START RDR edutech# * -- #is the completion of this machine's name
C:\>NET YPDOMAIN uci-ics
[ PC-NFS installed ] -- that part in inverse video
C:\>NET YPSET *
C:\>NET PCNFSD madeleinegw
C:\>NET NAME edutech changeme
These are all stages in starting the PC's connection with the net,
getting it the servers it needs, and giving it necessary
authorisation. They take varying amounts of time, from very fast
to quite slow, depending on the state and activity of other parts
of ICS's net, and the speed of the PC. For instance, NET START RDR
might take anything from
5 to 20 seconds. NET YPDOMAIN is usually almost instantaneous, but
it can slow down. So varying amounts of delay in these steps is not
a cause for alarm. However, excessive or unending delay (e.g. "NET
PCNFSD madeleine" appeared 3 minutes ago, and nothing is happening) is
likely a problem. Rebooting is usually the simplest solution; if
it keeps misbehaving, pressing ^C at or just after NFSRUN should be
safe -- the PC just won't be on the net.Once started, the network adds the following 2 properties, visible to the PC user:
For the PC to have remote drives to access, it must mount them, usually during startup. The same remote directory can be mounted by any number of PC's; in each case, the PC uses its own drive letter to refer to the remote drive, unaware of and unaffected by the other PC's doing the same. During mounting, the remote drives can be specified as either fully shared, or read-only. (In fact, the same remote drive may be mounted under different drive letters with different write permissions). This lets any number of PC's obtain the same resources from the common remote directory, with no unnecessary danger of one of them modifying it.
The PC now accesses the remote drive just as it does any other drive. Typically the DOS variable "PATH" will be set by AUTOEXEC.BAT to include directories on the remote drive (as well as directories that PC-NFS needs).
In this shared space at least the following things are made
available:
- the virtual volume files for the p-System. See below under p-
System Arrangement for more details
- DOSTOOLS\; a directory containing a number of DOS support
applications and utilities.
- 3-10TOOL\; a directory containing versions for DOS 3.10 of
utilities in DOSTOOLS, whose 3.30 versions won't run under DOS
3.10 . This is for the 5"-disc PC's, which must remain under DOS
3.10 .
The AUTOEXEC.BAT files on those machines place 3-10TOOL
ahead of DOSTOOLS in the PATH variable.
- TPASCAL\; a directory containing source, testing, and
experimentation directories for the Center's incipient developing
in Turbo Pascal.
- TPASC6\; Turbo Pascal version 6, containing object-orientation.
- NORTON\; a directory containing the full set of Advanced Norton
Utilities, for more powerful control of the DOS environment, and
for handling emergencies. (Should be upgraded to the latest
versions, especially since older Norton versions can have
difficulties with later versions of DOS.)
- MANAGE\; a directory containing managerial assistance programs,
such as spreadsheets.
(All the drivers, programs, and other components of PC-NFS are kept in the directory \NFS on each PC's hard disc. On PC's with more than one hard disc partition, NFS is kept on D: or E:, rather than the boot partition, to guard it from casual access.)
A corresponding software component called PCNFSD (for PC-NFS Daemon) must be running under UNIX (actually, SunOS) on at least one connected Sun. It is PCNFSD that actually watches for, and acts on, the requests for service from all the PC's. It also determines authorisation to access directories, as discussed above. When each PC mounts itself on the net, it requests that a Sun on the net supply PCNFSD services for it. (see configuration, below). The support group maintains PCNFSD use, in cooperation with ETC.
Following connection, the PC mounts itself on the net with several different calls to the NFS program NET. The actual calls are kept in the batch file NFS\NETWORK.BAT. A second batch file, NFS\DRIVES.BAT, supplies the NET calls which mount the various remote drives and printers. The list of possible calls to NET is given in the PC-NFS manual. Both are run from the program NFS\NFSRUN, which AUTOEXEC.BAT calls; they are written automatically by the interactive configuration program NFSCONF, when the user has chosen the desired configuration; they are editable by ordinary text editors.
NOTE: whenever NFSCONF is used to change the net's configuration,
it completely rewrites NFS\NETWORK.BAT, so if features
from the old
one are to be retained (e.g. if they were installed by later
editing), it will have to be saved under a different name.
Note the importance of this for the RARP problem
discussed just below.
NOTE: remote drives and printers are considered "resources" by PC-
NFS (NFSCONF has a separate menu for "resources"),
and not part of the configuration, so their arrangements can
be changed without affecting NFS\NETWORK.BAT .
Within NFSCONF, requesting RARP requires Yellow Pages to be ON.
(HINT: it may be wise to set the DOS file attribute "read-only" on NFS\NETWORK.BAT and NFS\DRIVES.BAT, to make it impossible for NFSCONF to alter them -- though it will probably appear to crash with a DOS I/O error as a result, in the process of quitting.)
"madeleine:~edutech" is an account providing shared file space for ETC's net. To DOS, to Windows 3.1, and non-NFS DOS programs, it appears when mounted to be the root directory on another DOS drive. There are also programs in \NFS\, such as LS.EXE and CHMOD.EXE, to handle the directory's UNIX facets -- protections, UNIX-length names, etc..
NOTE: The net communications programs "telnet" and "ftp" do not require the PC-NFSD daemon, and do not use the shared file space. They do, however, require Yellow Pages service. They can therefore be used even when the PCNFSD/file server is down, as long as they have a Yellow Pages server.
Unfortunately, it seems to be impossible for the current version of PC-NFS to broadcast a downtime warning from a server to the clients. This means that typically the only indication of the net's having lost file service during operations is that an access to the remote drives suddenly freezes. It will eventually produce the prompt "Abort, Retry, or Ignore" (if a DOS program is running), but not for a minute or more. Choosing "Ignore" is usually adequate to continue from the failed access.
(If the p-System is running at the time, all virtual volumes coming from the remote drive(s) will appear to have gone off-line, like floppy discs that have been ejected from their drives. The p-System usually detects I/O problems within a few seconds, and reacts with a certain degree of grace, but part of the system may have become inaccessible.)
In this configuration, no remote drives are available, but "telnet" and "ftp" will continue to function, with their normal range of access to machines (since Yellow Pages should still be available).
When AUTOEXEC.BAT itself finds that C:\NETDOWN.BAT exists, it runs it, rather than making any settings which assume the presence of remote drives. NETDOWN.BAT should therefore make whatever settings the PC requires to operate entirely locally. At least some of its settings are decribed under "p-System Arrangement", below.
NETDOWN.BAT is normally kept in the directory NETPSYS, which also contains local copies of the p-System virtual volume files. It takes effect when it has been copied into C:\ and the PC rebooted. If the file server is already down when the PC is being booted, it may be necessary first to break the running of NFSRUN with ^C (more than 1 may be necessary), copy NETPSYS\NETDOWN.BAT, and reboot.
To restore the PC to full net operation when the file server again becomes available, delete C:\NETDOWN.BAT (not the original), and reboot. Note that simply executing NFSRUN from the command line will not work.
To deal with this, some of the PC's have been supplied with a file analagous to NETDOWN.BAT, called NONET.BAT. On those machines, if C:\NONET.BAT is found to exist, running the net is suppressed entirely. (Loading the network device drivers is not suppressed, but this has not been found a problem, even in cases when the network adapter had been removed.)
As for NETDOWN.BAT, if and when network contact is restored, NONET.BAT needs to be removed from C:\, and the machine rebooted.
The program C:\PSYSTEM\PSYSTEM.COM boots the DOS-hosted p-System; it takes as arguments the names of the virtual volumes to be on-line when booting is finished. The first one is used as the boot volume. Note that full names must be given; the .VOL extension is not assumed.
After the PC has booted to DOS and mounted itself on the net, PSYSTEM.BAT can be used to boot the p-System on top of it.
The virtual volume file DOC.VOL is also kept on the remote drive, to provide on-line documentation of most of the menu choices in the p- System.
AUTOEXEC.BAT sets two environment variables to indicate the DOS directory path names from which p-System virtual volume files are to be read:
NETDOWN.BAT (see under Network Downtimes) sets them to directories local to the PC where copies of the virtual volumes are kept (e.g. "E:\NETPSYS\").
Since there is apparently no way to choose among SYSTEM.CONFIG files, a different main volume, MAIN5IN.VOL, is available for PSYSTEM.BAT to pass to PSYSTEM.COM on the machines whose #4: drive is 5.25". Its only difference is that #4: is configured the same as #5:. The consequences should not be significant: in particular, SYSTEM.LIBRARY is kept on TOOLS.VOL, to avoid duplicating it.
PC-NFS 3.0.1 has not generally been considered compatible with Windows, so it may be fortunate that it works this far. If the number of "drive" icons shown in File Manager's directory windows is too large for convenience, the last drive that DOS will permit can be lowered by setting LASTDRIVE=<letter-lower-than-Z> in CONFIG.SYS.
Because the assignment of ethernet address to internet address now holds within at least the "uci-ics" domain, any moving of network adapter between machines must be considered as taking the internet identity of the first machine and giving it to the second. So the NFS files on at least the second machine (\NFS\HOSTS and \NFS\NETWORK.BAT, at least) must be updated with the machine name and internet address assigned to the card being installed.
Not doing so will, at the least, cause possible tranmission problems for the machine receiving the card. It may also cause PC-NFS to detect two internet addresses as being assigned to the same ethernet card, and it may interpret that as a license violation, which it announces by taking over the screen to warn the user.
For non-Microchannel cards, the settings in CONFIG.SYS, at least, must agree with the physical jumper settings on the card. (These are described in the manuals for the cards). The card cannot successfully connect the machine to the net otherwise.
For Microchannel machines, even though LANMGR's PROTOCOL.INI file, under \NFS, shows settings for these addresses, those settings are not read; the card itself is interrogated for them.
WARNING: when using managers for expanded or extended
memory, it is essential to make sure they leave
as user-available RAM the 8K of high-memory addresses that the WD8003E
requires. (This includes omitting that 8K from the page-swapping scheme
for expanded memory under the LIMS 4.0 standard.) The more
sophisticated of these managers, such as
Quarterdeck's "QEMM" or Qualitas' "386 to the Max", supply parameters
for specifying that given RAM addresses are to be left free.
This is particularly important because the network card gives no
software-detectable indication at boot time that it will be using
that memory, so automatic detection of unused memory addresses
usually fails to reserve it.
One expanded memory manager that experience shows problems with is
TEMM.SYS, supplied with the Tandy's around 1988, which causes
ethernet access
to fail. However, since it doesn't seem to have the power of the
Quarterdeck or Qualitas memory organisation software anyway, omitting
it is no great problem.
Example:
DEVICE=PC-NFS.SYS /b1 /f30 /d10
They are named etc-xt00.ics.uci.edu and etc-xt01.ics.uci.edu . The form for etc-xt00.ics.uci.edu and the form for etc-xt01.ics.uci.edu provide fundamentals including memory size, ethernet addresses, and the UNIX machine that manages their X sessions.