uupc 3.1 Systems file This file must contain one line or more entries for each system that you wish to call. If there are other systems which will be calling you, but which you will not be calling, then you must also have lines in this file for them (one each)... or you can have an ANONYMOUS line to permit any uucp system in the world to call you. The general format of the lines in this file is: name time port dialer speed phone protocol expect send expect send ... where: name is the uucp name of a system which you will be calling, or will be calling you. The first seven characters are significant. There are two special reserved names... INCOMING is used to specify the port configuration to be used when answering incoming phone calls, and ANONYMOUS is used to specify that anonymous access is to be permitted (i.e., your system will accept an inbound uucp call from any uucp node anywhere). time is the times of day during which your system is permitted to place a phone call using the information on this line (or, in the case of the INCOMING entry, to accept phone calls using the information in this line). acceptable formats: "Any", "Evening", "Night", "hhmm-hhmm" hhmm-hhmm may be a inclusive range, ie: 0000-0600, or it can be an range that specifies morning and evening hours, ie: 1700-0700 (means 0000-0700 and 1700-2359) "Night" includes the standard AT&T night rate hours from 2300 to 0800 plus Friday evening, all day Saturday and Sunday until 1700. "Evening" include the standard AT&T evening and night rate hours. This includes all hours except 0800-1700 Monday thru Friday. Time may also include a retry interval (e.g. "evening;10") to specify the minimum retry interval. If a retry interval is specified, it will be used precisely as given. If no retry interval is specified, a HoneyDanBer-style exponential backoff algorithm is used... the retry time will be 5 minutes after the first failed attempt, 10 minutes after the second, 20 after the third, and so forth... up to a maximum backoff of 23 hours. port specifies which serial port should be used. 'a' is the modem port, and 'b' is the printer port. If you have additional serial ports with standard "shadow" drivers... if they can be accessed as devices ".Cin" and ".Cout", ".Din" and ".Dout", etc... then you can specify such ports as 'c', 'd', and so on through 'd'. You can also access a Communications Toolbox configuration, by "CTB/name" where "name" is the name of the configuration as it appears in the UUPC "CTB" menu. See the "UUPC & the Comm Toolbox" document for details. dialer specifies the autodialing method to use. DIR means "direct connect". It can be used when your Mac is directly connected to another system, can be used to issue dialing commands to a nonstandard modem via the send/expect chat strings, and is frequently used when you specify a Communications Toolbox configuration as the connection port and are depending on the CTB tool to establish the connection. HAYES means "Hayes-compatible modem". You may specify "HAYES+string" to specify additional options to be sent to the modem during the handshaking sequence (e.g. setting S-registers), or "HAYES!string" to specify options and to tell the dialer to ignore the speed returned in the CONNECT message (i.e. "lock" the Mac-to-modem speed), or "HAYES*string" to specify options, lock the Mac-to-modem speed, enable hardware-handshaking flow control, and use the HAYES software-disconnect sequence (pause, +++, pause, ATH0). VADIC means "Racal-Vadic VS212P modem"... does anybody else actually own one of these? Important note if you include a "+string" or "!string" as part of the HAYES dialer specification: the string is sent using the \-substituion rules described below for "send" strings. Remember to double any backslashes that your modem expects to see (e.g. to send the string \F to your modem as part of the handshake, use HAYES+\\F). speed specifies the bit rate at which the serial port should be configured. The standard port rates are supported, up to 57600 bps. You can also embed Communications Toolbox options in this position - see the "UUPC & the Comm Toolbox" document for details. phone specifies the phone number to be dialed. It can be a simple string of digits (the Hayes dialer will prepend 'DT' to it), or a complex string of modem options and digits (in whcih case you must include a 'D' or 'DP' or 'DT' to start the dialing) or a '-' character which means "none". The '-' form will usually be used with a DIR connection, or in the specification of an INCOMING call. You can also embed Communications Toolbox options in this position - see the "UUPC & the Comm Toolbox" document for details. protocol specifies the uucp protocol which should be used. The usual protocol is 'g'... uupc 3.0 defaults to a 3-packet window, and will negotiate down to a smaller window based on its peer's advertised maximum window size. You may also specify 'g' with a larger window size... e.g 'g7'... if your peer supports a larger window and can actually handle it properly. Some systems will negotiate a 7-packet window, but can't really support it (e.g. at 9600 bps, Ultrix drops packets in a 7-packet window but handles them fine if the window is limited to 3 packets). You may also change the packet size used by the 'g' protocol, from its normal value of 64 bytes to 128, 256, 512, 1024, 2048, or 4096 bytes. To specify an alternate packet size, you must specify both the window size and packet size... e.g. 'g3/128' or 'g3!128". A separator of '/' tells uupc to ask its peer to send larger packets, and to send whatever size of packet its peer asks it to. A separator of '!' tells uupc to ask its peer to send larger packets, and to send packets of the specified size _regardless_ of what its peer says (this is a violation of the protocol specification, but is occasionally useful). Very few uucp implementations will agree to receive larger packets from uupc. A few can send 128-byte packets, even if they cannot accept them in return, but will fail if you ask them to send you 256-byte packets. The 'f' protocol is also supported. This is a streaming protocol, designed to operate over nearly-error-free, flow- controlled, 7-bit-wide data links... specifically, over X.25 packet-switched networks via an X.25 PAD. It can also be used over modems which support MNP (level 3 or 4) or V.42. It works very nicely over MNP 5 and V.42bis modems with data compression. Not many uucp implementation support the 'f' protocol (it's a BSD-ism). send represents a string to send. A carriage return is automatically appended, unless a \c sequence appears within the string. expect represents a string to expect (wait for). Try-again sequences are specified with hyphens... e.g. A-xxx-B means "wait for A, if you don't see it within the timeout interval, send xxx and then wait for B". You may have two or more lines in the Systems file for any uucp system-name. The lines may specify different calling times, ports, dialers, speeds, protocols, and send/expect sequence. When uupc 3.0 attempts to place a call to your neighbor, it will try the lines one after another until it [a] finds a line that it can use at the current time and [b] places a successful call to the neighbor. If you have more than one line in the Systems file for a neighboring site, put all of these lines together... don't intersperse lines which apply to other systems. If you do, uupc 3.0 will sometimes call the neighbor more than once in a single processing run. The send and expect strings both permit the use of escape sequences of various sorts. The following escapes can be used in the "expect" strings: \r - expect a carriage return \n - expect a newline \t - expect a tab \ - (backslash space) - expect a space \\ - expect a backslash \x - where "x" is not one of the above - expect "x" itself. Ą - (option-8) - end of "expect" string, beginning of "don't expect" string. If the string which follows the Ą character should appear before the string which preceeds it, abort the call attempt immediately. Multiple don't-expect strings can be used, separated by Ą characters. The following escapes can be used in the "send" strings: \d or \D - delay two seconds \r or \R - send a carriage return \m or \M - send a carriage return \n or \N - send a newline \t or \T - send a tab \s or \S - send a space \c or \C - do NOT append a carriage-return to the end of the string \p or \P - pace the remainder of the string - send at a rate of roughly 15 characters per second \# - where # is a decimal number - change the expect-string timeout to the specified number of seconds \Z#\ - where # is a decimal number - change the serial-port baud rate to the specified number. \\ - send a backslash ^x - where "x" is an ASCII character... send a control-x \^ - send a ^ character There are several special "send" strings BREAK - send a 300-millisecond "break" signal (a "long space") BREAKn - where 'n' is a digit between 1 and 9 - sent an n-hundred- millisecond long space (e.g. BREAK6 sends a 600-millisecond break signal) P_EVEN - switch the connection to 7 data bits, even parity P_ODD - switch the connection to 7 data bits, odd parity P_NONE - switch the connection to 8 data bits, no parity The INCOMING entry is treated somewhat specially. If the HAYES dialer is specified, it is called and instructed to configure the modem to allow incoming phone calls to be answered, and to wait for such a call-and-answer sequence to occur. After the dialer detects an answer (or immediately, if the HAYES dialer is not used), the chat script is executed. Finally, a pseudo-login shell is run... it prompts the caller for a "Username:", and then a "Password:". The password must match the contents of the PASSWORD configuration string... if it does, the username is displayed on the uucp console window, and protocol startup is performed. If an incorrect password is entered, it is rejected and the caller is prompted for the username once again.