The Local User Directory (LUD)

The LUD is an NS record collection. It has an entry for every username known to Gnosis. The name of an entry is the uppercase ASCII username. The data from the entry is called the "LUD string" {(ludstring)}. The key in the entry is a node key to the "user-lud-node" {(ludformat)}.

There is also an entry which receives circuits from users who are strangers to Gnosis. Its name is one byte of zero.

Currently this entry asks the user who he is and looks up his name in the LUD like the receptionist. You must supply a system-wide password.

The following is a procedure to allow application developers to add names to the LUD.
USER.ADDLUDKY is called (The ADDLUDKY command in the old command system works here).

ADDLUDKYF(0;SB,M,LUD ==> c;ADDLUDKY) produces an addludky for a particular LUD.

ADDLUDKEY(0, (1,nl)(nl,name) (1,pl)(pl,password) (1,sl)(sl,ludstring); KEY,SPACEBANK,METER ==> c;MODIFYLUD)

KEY is the key that will be called by the receptionist

SPACEBANK and METER are used to build the low level circuit domains

Each of the three strings is preceded by a length byte. The name string can be 17 bytes, the password string can be 11 bytes and the string for the lud can be 35 bytes long.

"name" and "password" are in EBCDIC.

return codes:

c = 0 good

c = 1 can't add name because it is not unique

c = 2 can't build the red segment used as the MODIFYLUD key

c = 3 can't create a node

c = 4 parameter length error

c = 7 SPACEBANK is not official

c = 8 internal error

The LUD string is defined as follows.
1 BYTE LUD format see (p2,ludformat)

If there is a password, this is followed by:

1 BYTE Flag indicating whether the password is encrypted or not (1 if encrypted, 0 if not)

16 BYTES of password. Either the 16 byte encrypted value or the clear value blank filled (ASCII)

ADDLUDKEY(1, (1,nl)(nl,name) (1,pl)(pl,password) (1,sl)(sl,ludstring); KEY,SPACEBANK,METER ==> c;MODIFYLUD)
Same as ADDLUDKEY(0...) except that "name" and "password" are ASCII.

ADDLUDKEY(kt; ==> x'02a')

MODIFYLUD(0,string;NODE ==> c)

"string" is a byte string up to 35 characters that becomes the new LUD string. See (p2,ludstring). If omitted, the LUD string is unchanged. If the offered string is less than 18 bytes (cannot be a password) only the first byte is replaced in the LUD.

"NODE" is a node with

Slot 0 the new LUD key

Slot 1 a Spacebank key

Slot 2 a Meter key

Return codes
0 = change done

1 = Lud name deleted while update in progress

4 = Lud string longer than 35 characters

7 = Slot 1 of node does not contain an official spacebank

MODIFYLUD(kt; ==> x'22a')

MODIFYLUD(kt+4 ==> 0) deletes the LUD entry and destroys the MODIFYLUD key

Each LUD entry has a node key to a user-lud-node. Slots 0 and 1 of this node hold a bank and meter for use by the receptionist to serve the user. The LUD string specifies how the key is to be called.
.) If the string is empty or its first byte is zero:
The key in slot 2 of the user-lud-node is called as a ZMK {(p2,zmk0)}. A TCEM is built by the receptionist (but the TCEMK key is lost).
In familiar cases the key from the LUD is a ZMK key ((p2,zmk)) that leads to a command language interpreter (CLI) {(p2,cli)}.

There is no currently defined function ascribed to the resume key. It is polite to jump to it soon.

If the first byte of the string is 1:
The key is forked to like LUDKEY(0, (4,soklimit), (4,tymnet header), (1,shut override flag), (1,login line terminator); SIK, SOK, CCK).

The shut override flag is 1 if the circuit had shut override, 0 otherwise. The login line terminator is ASCII carriage return or semicolon. The Tymnet header has the terminal type and the originating node and port number.

If the first byte of the string is 2:
A TCEM is built by the receptionist. The key from the LUD is forked to like LUDKEY(0, (4,sok2limit), (1,unamelen), (unamelen, uname); SIK2, SOK2, CCK2, TCEMK) where uname is the Tymnet username. If you dialed in, uname is the null string and the last key parameter is DK(0).

If the first byte of the string is 3:
A TCEM is built by the receptionist. The key from the LUD is forked to (using extended jump protocol) like LUDKEY(0, (4,sok2limit), (1,unamelen), (unamelen, uname); SB, METER, SB, SIK2, SOK2, CCK2, TCEMK) where uname is the Tymnet username. As with all extended jump invocations of factories, the string is passed on the second jump. Since the invocation is a fork, the last four keys are all passed on the second jump. If you did not come in through Tymnet, unamelen and uname are absent.

If the first byte of the string is 4: (Tymnet ONLY)
The key is returned to as LUDKEY(0;BEKEY,CCK) where BEKEY is a key to the receptionist back end and can be used to obtain information about the Tymnet circuit
BEKEY(0; ==> 0,(4,soklimit) (4,tymnetheader) (1,shut override flag) (1,login line terminator))

BEKEY(1;==>0,(ascii username))

BEKEY(2;==>0,(4,portnumber))

BEKEY(3;==>0;SIK,SOK,CCK) and BEKEY becomes DK0

Note the Tymnet receptionist has a timeout for new circuits. BEKEY will be destroyed after about ten minutes, so you should use it promptly.

See (p3,user-recon) for the current primary use of this function. See (login) for a proposed enhanced function.

The receptionist gets a set of keys and a port number {from the Tymnet Adaptor (p2,tymnet)} to a new circuit whenever the Tymnet supervisor builds one. The receptionist uses the user name from the circuit to select a key from a record collection called the LUD {local user directory}. The receptionist then assigns a domain to jump to this key {in case it isn't very prompt} and then starts that domain. If the key from the directory remains busy too long, or if the receptionist has {inadvertently} buffered data from the circuit and has to wait too long to deliver it, the receptionist will zap the circuit {perhaps with apologies} and retrieve the domain.

TYMLRECE Factory

TYMLRECEF(0;SB,M,TLABNODE ==> 0;TYMLRECE) Create the Tymnet receptionist
TLBANODE is a node with TLBA {(tlba)} keys to all configured bases.

TYMLRECEF(kt; ==> X'10D0E';)

TYMLRECE Key
TYMLRECE(0,(2,hostno); ==> ;) Set host number
Sets the host number to be used the next time any base is started.

TYMLRECE(1; ==> ;) Stop and Restart base 0. Same as order code 256+9

TYMLRECE(2; ==> ;) Same as order code 256+15

TYMLRECE(3; ==> ;CRC) Return CRC

The CRC is a named sequence record collection. When a circuit is built to Gnosis, a record is added. The name of the record is 4 bytes of binary base number followed by 4 bytes of binary port number. The string is the 4 byte Tymnet header, 1 byte shut override flag, 1 byte login line terminator, 1 byte username length, and the username (Ascii), in that order. The key is the CCK for the circuit.

When a circuit is zapped, the record that represents it may remain in the CRC for a long time. Its CCK key of course becomes DK(0).

At the time the CRC key is returned, such records are searched for and deleted. This takes time proportional to the number of circuits and so is a moderately expensive operation.

TYMLRECE(4; ==> ;TBLKNODE) returns a fetch key to a node with a TBLK key for each base that exists.

TYMLRECE(5, (1,time); ==> ;) Set timeout

Sets the timeout to be used the next time any base is started. If time is even, the timeout is long; if odd, short.

TYMLRECE(6; ==> ;LOGSNODE) returns a fetch key to a node with a log key for each base.

TYMLRECE(256+b*16+f; ==> ;) Perform functions

b < 16 and f < 16. The indicated functions are performed in the following order for base number b. (F can be viewed as a binary number, with each bit controlling a function.)

If (f/8) mod 2 >= 1, the base is stopped

If (f/4) mod 2 >= 1, the TLA for the base is torn down.

If (f/2) mod 2 >= 1, a TLA is built for the base.

If (f/1) mod 2 >= 1, the base is started. (The base is initially shut.)

The caller is responsible for ensuring the integrity of sequences of operations. A base cannot be torn down unless it is stopped, cannot be stopped unless it is started, cannot be started unless it is built, etc.

Note that the ability to do several steps in one call is useful if an intermediate step results in the system's only base being down.

TYMLRECE(kt; ==> X'D0E';)

TYMLRECE(kt+4; ==> ;) Destroy the receptionist.

The caller must ensure that all bases are stopped and torn down first.

{arcane}{nonref}{ni}Multi-Base support (Tymnet Liaison)
Tymnet liaison ("liaison" here) a program that comes before the receptionist that is cognizant of a set of Tymnet bases. Liaison is born with a set of TBA keys, each for a different Tymnet base.

Liaison controls whether a TA {(p2,tymnet)} is polling its base. When a TA is polling its base it tries to communicate with its base about every 15 seconds. Otherwise it tries less than once per hour or perhaps never.

Each base is polled once shortly after the kernel is IPL'ed.

Liaison can be requested, via a key meant to be held by an operator, to begin or cease polling a particular base.

Liaison is also in contact with its TA's and will cause the polling of all bases while there are no circuits from any of the bases.

This is to protect against the situation where all of the good bases are in the non-polling state and the operator can't get in to request the polling {and subsequent start-up} of any good base.

Liaison might also perform the functions alluded to in (p2,ta-friend).

Design Notes
The receptionist is the program in a position to establish the policy about who can request new circuits of the network supervisor. This is because it holds the control key to the Tymnet adaptor.

{arcane}{nonref}Design Note: The receptionist is designed to remove any function from the Tymnet adaptor that is not strictly connected with the multiplexing of Tymnet and at the same time keep questions of authority based on knowledge of Tymnet passwords out of the logic of Command language interpreters. Also the "WHO" and "ZAP CIRCUIT" facilities must handled by a central program.

{ni}Design Proposals
Knowing Tymnet User Names
There ought to be a way for people converse with the system without having been validated in the LUD. I propose the following:

When a new circuit is found to have a user name not in the LUD there should be a standard program that the receptionist calls.

I shall call this program the "guest server". The guest server gets the user name. It is in a position to carry out several policies of which I enumerate a few:

A menu of a few gratis services that Tymshare might choose to provide might be made available. The guest server is in a position to note abuse since the Tymnet user name is uncounterfeitably known and records may be kept.
Mail

Tymnet wide teleconferencing

Establishing Auxiliary circuit capabilities
We propose here that when the receptionist receives a notification of a new circuit and the user name of that circuit is unknown to the LUD that a guest program be run.
This program would allow the guest to send, via the Gnosis mail system, a key that would provide the authority to build circuits to other machines on Tymnet under the name of the unknown user.

See (p2,getcircuitc) regarding available function.

There remains an awkward problem, how to provide the same service to our known users. The receptionist could pass such a circuit initiating key with each circuit initialization. The domain generated by the receptionist could do this if called by the routine fetched from the LUD.

The guest server may negotiate with the user and validate the user in the LUD.

Some of the gratis services require uncounterfeitable knowledge of the user name.
To this end I propose two kinds of keys, the "user name" and the "user namer".

There is just one "user namer" UNR. For each possible user name x there is {potentially} a user name key UN such that UNR(0;UN==>0,x).

Users may endow domains with the authority to do their bidding with services that distinguish clients on the basis of their Tymnet user names by giving such domains their user name key.

These keys would be supported by the receptionist or a friend thereof.

Such services may learn the Tymnet user name that a caller is invoking by repassing the user name key to UNR whence it learns the real user name.

I currently have grave misgivings about this idea. See the story "True Names" by Vernor Vinge, Dell books for some philosophical reasons.
The issue is whether servers have the right to know the true Tymnet names of their clients.

A less political issue is whether proving to someone that you have the authority of a Tymnet user name should allow him to assume that mantle in other contexts. The above scheme has that defect.

A better scheme?
Let there be an "introducer" INTRO that is trusted by all.

Let there be a kind of key "user name" provided by the receptionist to either the guest server or the entry key from the LUD.

Let F be a requestor's key to a factory and let N be a user name key provided by the receptionist as a new circuit built by user name n.

INTRO(F,N,SB,M==> 0,E) causes the .program of F to be run as usual but with the user name n in in the floating registers.

This scheme convinces the .program that the holder of E is acting under n's authority. This scheme is also convoluted and uncomfortably involved with factory design. It avoids the problem stated in (glitch).

{arcane}{nonref}{ni}Knowing Who's On
The receptionist also makes a record {perhaps indexed on Tymnet port number} of the circuit. In this record the receptionist keeps the user-name, node number, a circuit control key and whatever else was known about the circuit when it was created. A friend of the receptionist will answer questions about this record including whether the circuit control key still exists, indicating that the circuit still exists. Another friend will zap a circuit.

The TENEX "who" command reports for each circuit how long ago there was traffic. This information is very suggestive of the commitment of the system to sustain operation in support of interactive applications. It is also the most obvious indicator of degree of involvement of the people with the system, which in turn, leads to a feeling of the portion of the current system load due to interactive applications.

This information is easy and cheap to gather by the Tymnet Adaptor. It is the only central place to gather it. There may be a security issue here: the receptionist and Tymnet institution may know things that bear on the security issues involved with a given circuit.

This information might be returned, upon request, to the holder of the TBLK key, or perhaps a weakened version of it.

The GTT receptionist is designed for use when Gnosis is running under Tymshare's version of CP. When you dial into the GTT receptionist you get to the GTT receptionist, which will ask you for a password and username.

WARNING!! If you type ESC or US too fast after dialing, you can get into trouble. It is not too fast if you wait until it has typed at you.

Gnosis is currently configured so that the GTT receptionist answers VM dial ports 20 thru 23.

RECEPFF(kt==>X'13E')

RECEPFF(0;SB,M,LUD ==> c;RECEPF)

RECEPF is a factory requestor's key to a receptionist. To invoke the receptionist:

RECEPF(kt+5;PSB,M,SB=>kt+5;,,,CO); FORK
CO(0,((4,sok2limit),(1,unamelen),(unamelen, uname)); SIK2,SOK2,CCK2,TCEMK)
'uname' is the Tymnet username. If there is no Tymnet username, uname is the null string.
The receptionist will use SIK2, SOK2, CCK2, and TCEMK as the keys to the terminal.

RECEPF(kt==>X'3E')

This receptionist works with both TYMNET and 3270 terminals. R3270 (the 3270 terminal driver) supplies a null string on the second call. With a null string the receptionist puts up a LOGO and prompts for a username and password.