perm filename INFO.TXT[HST,NET] blob sn#768181
filedate 1984-09-06 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00007 PAGES
C REC PAGE DESCRIPTION
C00002 00002 Host Table Information
C00004 00003 Tables and Table Formats
C00007 00004 Update Procedure at SAIL
C00012 00005 Update Procedure at S1-A
C00014 00006 Files on [HST,NET]
C00016 00007 Other useful files
Host Table Information
Host tables are used to translate between host names (text strings supplied by
the users of network programs) and host numbers required by the operating
system. The directory [HST,NET] contains most of the files pertaining to host
As of June 1983, we use an internal form of host tables known as HOSTS3. This
is a PDP-10-based representation designed especially for Internet host names and
numbers, corresponding to the format outlined in RFC 810. HOSTS3 format also
handles PUP host numbers on Stanford's local Ethernet.
Host tables change from time to time, and they must be kept up-to-date. At
SAIL, this is done by checking for a new version of the Network Information
Center (NIC) host table once a day, and retrieving it if it has changed; also
checking for a new version of the PUP network directory. The PUP network
directory is converted from its binary form to a text file in RFC810 form. It
and the NIC table are then merged into the HOSTS3-format binary table.
The eventual plan is to replace the use of the host table by queries to network
name servers. This was supposed to become operative beginning in the spring of
1984, but the schedule has already slipped by several months.
Tables and Table Formats
The specification of the text form of host tables can be found in RFC 810,
available as the file <NETINFO>RFC810.TXT at SRI-NIC. (If a local copy is kept,
it should be stored as RFC810.TXT[RFC,NET].) It is not too important that this
syntax be understood, because the HOSTS3 program takes care of the details. The
latest copy of the NIC host table is stored as <NETINFO>HOSTS.TXT at SRI-NIC,
but it is retrieved using the Hostname Server rather than with FTP. It is
stored as HOSTS.TXT[HST,NET] at SAIL.
A description of the binary format of the PUP Network Directory can be found in
the file <Pup>PupDirectory.press on the IFS. The directory is stored in binary
form on several hosts; the master copy should be at Navajo in the file
/usr/local/Pup-Network.Directory. It is retrieved using the PUP Network
Directory Update protocol, and stored as PUPNET.DIR[HST,NET] at SAIL.
Sometimes we retrieve the text source used to generate this directory, although
it is not read by any programs on SAIL. It is stored as PUPNET.TXT[HST,NET].
The file PUPHST.TXT[HST,NET] contains a locally-generated text form of the PUP
Network Directory, in RFC810 format to allow merging with HOSTS.TXT[HST,NET].
An Ethernet host number such as 50#302# is shown in the file as SU 50#302.
Finally, HOSTS3.BIN[HST,NET] is the binary host table read by most network
programs. Its format is described in comments in the files HOSTS3.MID[HST,NET],
NETWRK.MID[S,NET] and NETWRK.FAI[S,NET].
There is also a text file, TTYLOC.TXT[HST,NET], giving TTY locations for
Ethertip ports and other local Ethernet hosts. This is maintained at Score.
There is no binary form; programs that read the file (currently only CHTSER,
using the TTYSTR routine in the NETWRK package) interpret the text.
Update Procedure at SAIL
At present, the update procedure is semi-automatic. It will eventually require
no intervention unless unexpected errors are encountered.
At 3:00 a.m. each day, [HST,NET] runs a batch job (BAT0), which runs the
program UPDATE[HST,NET]. Currently this program does the following things.
1. Queries the NIC Hostname Server to find out the version of its HOSTS.TXT.
(This is returned as a string. If you want to do it manually, the
easiest way is to Telnet to port 101 (decimal) at SRI-NIC, and type the
2. Reads the version string corresponding to SAIL's current HOSTS.TXT. This
string is stored in HOSTS.VER[HST,NET].
3. If they are different, retrieves a new HOSTS.TXT from the Hostname Server
(using the "ALL" command).
4. Reads the version of our current PUP Network Directory, which is stored
in the header part of the file (PUPNET.DIR[HST,NET]).
5. Broadcasts this version number in a PUP packet, which will elicit responses
from any hosts who have a higher version number.
6. Requests a new directory from any host that claims to have a higher number.
This is stored in PUPNET.DIR[HST,NET], and also converted to text form and
stored as PUPHST.TXT[HST,NET].
If either the NIC host table or the PUP Network Directory was updated, UPDATE
then sends a message to BUG-HOST (currently, this forwards to JJW).
By examining BAT0.LOG, you can see which of the tables was updated. To actually
see what has changed, you have to compare the new files with saved versions of
the old files. This is currently done manually using SRCCOM; eventually UPDATE
may do this automatically. If the changes are trivial, you may not want to
bother making a new HOSTS3.BIN.
To merge HOSTS.TXT and PUPHST.TXT and write a new binary host table, type
This will install a new HOSTS3.BIN, if all goes well. You may get a "duplicate
host name" message for the host MORDOR, since S1-C has this as a nickname, and
there is a different Mordor in the PUP table. This error isn't serious, as long
as no one wants to get to the Stanford Mordor.
The TTY location file is not automatically updated. To get a new version of it,
give the command
It may be useful to SRCCOM the old and new versions to detect changes.
To update the text version of the PUP Network Directory (which is kept here as
PUPNET.TXT[HST,NET] for unofficial purposes only), retrieve it (in Ascii mode)
from one of the following places:
; Stored on: [Navajo]/usr/local/Pup-Network.tx /* MASTER COPY */
Update Procedure at S1-A
S1-A's update procedure is actually more automatic than SAIL's. It runs a
version of the UPDATE program at 3:00 every morning, that checks for a new host
table at SRI-NIC, and it there is one, uses FTP (running on a PTY subjob) to
retrieve a new copy of HOSTS3.BIN from SRI-NIC.
This avoids having to run the HOSTS3 program at S1-A, but it depends on SRI-NIC
keeping their HOSTS3.BIN current with respect to their HOSTS.TXT. So far, they
seem to be doing so.
S1-A thus has no access to names in the Stanford PUP network directory (except
for hosts also in the NIC host table), but it has no real need for these.
Files on [HST,NET]
BAT0.DMP The nightly batch job
BAT0.LOG Batch job output log
DO.DO Various DO command segments
HOSTS.TXT Latest version of the NIC host table
HOSTS.VER Version string corresponding to HOSTS.TXT
HOSTS3.BIN HOSTS3-format binary host table
HOSTS3.DMP Program to produce HOSTS3.BIN
HOSTS3.MID Source for HOSTS3.DMP
MERGE.TXT Input for HOSTS3 program to merge NIC and PUP tables
PUPHST.TXT RFC810 form of PUP Network Directory
PUPNET.DIR Latest version of PUP Network Directory
PUPNET.TXT Text source of PUP Network Directory
TTYLOC.TXT TTY locations, for FINGER
UPDATE.CTL Commands for nightly batch job
UPDATE.DMP Program to retrieve host tables
UPDATE.FAI Source for UPDATE.DMP
Other useful files
NETWRK.FAI[S,NET] FAIL version of the NETWRK I/O package
NETWRK.MID[S,NET] MIDAS version of the NETWRK I/O package
Most of the programs on [S,NET] read the host table. Other programs that do are
NXP[SPL,SYS] (to find Boise's address)
PRESS.FAI[CSP,SYS] (to find the Dover's address)
(Please add to the above list any other programs that you know of.)
∂06-Sep-84 1355 ME host table updating
To: JJW@SU-AI.ARPA, "#INFO.TXT[HST,NET]"@SU-AI.ARPA
I'm about to leave for three weeks, so I thought I'd tell you what I've
been doing when host table update notices come in.
I have two DO segments on HST,NET that do the SRCCOMs for the NIC and PUP
host tables. DO HOSTS is for the NIC and DO PUPHST is for PUP. When I
get a notification from your UPDATE program, I alias to HST,NET, look at
BAT0.LOG to see which host table(s) changed, and then DO HOSTS and/or DO
PUPHST. Those DO segments want for the (last 3 digits of) the new and old
host table versions. A copy is made of the new version and then a SRCCOM
is made of that copy with the copy previously made of the old version.
The result file of the SRCCOM is mailed to a file on HST,NET and then
deleted, and you are left with your line editor holding a command to edit
the .MSG file at the right place where the new stuff is.
This way, a record of changes is maintained, for each of the two host
After you've scanned the changes, you can DO MERGE to make the new binary
file and then delete the copy of the old host table version. The latter I
do by saying DR .3*<cr> and then delete the old versions with DIRED. Of
course, this only works because both version numbers are currently in the
It would be nice if you could automate some of this in the UPDATE batch
sequence (better, in UPDATE itself), with the final result of running
UPDATE being the SRCCOM differences being mailed to the .MSG file(s).
Actually, at this point, I wouldn't mind if the new host table were put up
automatically at SAIL, as long as the SRCCOMs are available for perusal
later, should any problem crop up. Thanks.