This chapter provides reference information for working with UUCP. The following topics are covered:UUCP /etc/uucp/Systems File UUCP /etc/uucp/Devices File UUCP /etc/uucp/Dialers File Other Basic UUCP Configuration Files UUCP /etc/uucp/Permissions File UUCP /etc/uucp/Poll File UUCP /etc/uucp/Config File UUCP/etc/uucp/Grades File Other UUCP Configuration Files UUCP Administrative Files UUCP Error Messages The /etc/uucp/Systems file contains the information that is needed by the uucico daemon to establish a communication link to a remote computer. /etc/uucp/Systems is the first file that you need to edit to configure UUCP. Each entry in the Systems file represents a remote computer with which your host communicates. A particular host can have more than one entry. The additional entries represent alternative communication paths that are tried in sequential order. In addition, by default UUCP prevents any computer that does not appear in /etc/uucp/Systems from logging in to your host. By using the Sysfiles file, you can define several files to be used as Systems files. See UUCP /etc/uucp/Sysfiles File for a description of Sysfiles. The following is the syntax for an entry in the Systems file:System-Name Time Type Speed Phone Chat ScriptSee the following example of an entry in the Systems file.Arabian Any ACUEC 38400 111222 ogin: Puucp ssword:beledi ArabianEntry for the System-Name field. For more information, see System-Name Field in /etc/uucp/Systems File. AnyEntry for the Time field. For more information, see Time Field in /etc/uucp/Systems File. ACUECEntry for the Type field. For more information, see Type Field in /etc/uucp/Systems File. 38400Entry for the Speed field. For more information, see Speed Field in /etc/uucp/Systems File. 111222Entry for the Phone field. For more information, see Phone Field in /etc/uucp/Systems File. ogin: Puucp ssword:belediEntry for the Chat Script field. For more information, see Chat-Script Field in /etc/uucp/Systems File. This field contains the node name of the remote computer. On TCP/IP networks, this name can be the machine's host name or a name that is created specifically for UUCP communications through the /etc/uucp/Sysname file. See UUCP /etc/uucp/Systems File. In Example 26–1, the System-Name field contains an entry for remote host Arabian. This field specifies the day of week and time of day when the remote computer can be called. The format of the Time field follows: daytime[;retry] The day portion can be a list that contains some of the following entries. Su Mo Tu We Th Fr SaFor individual days. WkFor any weekday. AnyFor any day. NeverYour host never initiates a call to the remote computer. The call must be initiated by the remote computer. Your host is then operating in passive mode. Example 26–1 shows Any in the Time field, which indicates that host Arabian can be called at any time.The time portion should be a range of times that are specified in 24-hour notation, for example, 0800-1230 for 8:30 a.m. to 12:30 p.m. If no time portion is specified, any time of day is assumed to be allowed for the call.A time range that spans 0000 is permitted. For example, 0800-0600 means all times are allowed other than times between 6 a.m. and 8 a.m. The retry subfield enables you to specify the minimum time (in minutes) before a retry, following a failed attempt. The default wait is 60 minutes. The subfield separator is a semicolon (;). For example, Any;9 is interpreted as call any time, but wait at least 9 minutes before retrying after a failure occurs. If you do not specify a retry entry, an exponential back-off algorithm is used. This means that UUCP starts with a default wait time that grows larger as the number of failed attempts increases. For example, suppose the initial retry time is 5 minutes. If no response occurs, the next retry is 10 minutes later. The next retry is 20 minutes later, and so on until the maximum retry time of 23 hours is reached. If retry is specified, the value specified is always the retry time. Otherwise, the back-off algorithm is used. This field contains the device type that should be used to establish the communication link to the remote computer. The keyword that is used in this field is matched against the first field of Devices file entries. Arabian Any ACUEC, g 38400 1112222 ogin: Puucp ssword:beledi You can define the protocol that is used to contact the system by adding the protocol to the Type field. The previous example shows how to attach the protocol g to the device type ACUEC. For information about protocols, see Protocol Definitions in /etc/uucp/Devices File. This field, also known as the Class field, specifies the transfer speed of the device that is used in establishing the communication link. The UUCP speed field can contain a letter and speed, such as C1200 or D1200, to differentiate between classes of dialers. Refer to Class Field in the /etc/uucp/Devices File. Some devices can be used at any speed, so the keyword Any can be used. This field must match the Class field in the associated Devices file entry. eagle Any ACU, g D1200 NY3251 ogin: nuucp ssword:Oakgrass If information is not required for this field, use a dash (-) as a placeholder for the field. This field enables you to specify the telephone number, known as a token, of the remote computer for automatic dialers, which are known as port selectors. The telephone number consists of an optional alphabetic abbreviation and a numeric part. If an abbreviation is used, the abbreviation must be listed in the Dialcodes file.nubian Any ACU 2400 NY555-1212 ogin: Puucp ssword:Passuan eagle Any ACU, g D1200 NY=3251 ogin: nuucp ssword:Oakgrass In the Phone field, an equal sign (=) instructs the ACU to wait for a secondary dial tone before dialing the remaining digits. A dash (-) in the string instructs the ACU to pause four seconds before dialing the next digit.If your computer is connected to a port selector, you can access other computers that are connected to that selector. The Systems file entries for these remote machines should not have a telephone number in the Phone field. Instead, this field should contain the token to be passed to the switch. In this way, the port selector knows the remote machine with which your host wants to communicate, usually just the system name. The associated Devices file entry should have a \D at the end of the entry to ensure that this field is not translated by using the Dialcodes file. This field, also known as the Login field, contains a string of characters that is called a chat-script. The chat script contains the characters the local and remote machines must pass to each other in their initial conversation. Chat scripts have the following format:expect send [expect send] ....expect represents the string that the local host expects to receive from the remote host to initiate conversation. send is the string that the local host sends after the local host receives the expect string from the remote host. A chat script can have more than one expect-send sequence. A basic chat script might contain the following: Login prompt that the local host expects to receive from the remote machine Login name that the local host sends to the remote machine in order to log in Password prompt that the local host expects to receive from the remote machine Password that the local host sends to the remote machine The expect field can be composed of subfields of the following form:expect[-send-expect]...The -send is sent if the prior expect is not successfully read. The -expect that follows the -send is the next expected string. For example, with strings login--login, the UUCP on the local host expects login. If UUCP receives login from the remote machine, UUCP goes to the next field. If UUCP does not receive login, UUCP sends a carriage return, then looks for login again. If the local computer initially does not expect any characters, use the characters "", for NULL string, in the expect field. All send fields are sent with a carriage return appended unless the send string is terminated with a \c.The following is an example of a Systems file entry that uses an expect-send string: sonora Any ACUEC 9600 2223333 "" \r \r ogin:-BREAK-ogin: Puucpx ssword:xyzzyThis example instructs UUCP on the local host to send two carriage returns and wait for ogin: (for Login:). If ogin: is not received, send a BREAK. When you do receive ogin:, send the login name Puucpx. When you receive ssword: (for Password:), send the password xyzzy. The following table lists some useful escape characters.Escape Character Meaning \b Sends or expects a backspace character. \c If at the end of a string, suppresses the carriage return that is normally sent. Ignored otherwise. \d Delays 1–3 seconds before sending more characters. \E Starts echo checking. From this point forward, whenever a character is transmitted, UUCP waits for the character to be received before continuing its checks. \e Echoes check-off. \H Ignores one hangup. Use this option for dialback modems. \K Sends a BREAK character. \M Turns on CLOCAL flag. \m Turns off CLOCAL flag. \n Sends or expects a newline character. \N Sends a NULL character (ASCII NUL). \p Pauses for approximately 1/4 to 1/2 second. \r Sends or expects a carriage return. \s Sends or expects a space character. \t Sends or expects a tab character. EOT Sends an EOT, followed by newline twice. BREAK Sends a BREAK character. \ddd Sends or expects the character that is represented by the octal digits (ddd). Some companies set up dial-in servers to handle calls from remote computers. For example, your company might have a dial-in server with a dialback modem that employees can call from their home computers. After the dial-in server identifies the remote machine, the dial-in server disconnects the link to the remote machine and then calls back the remote machine. The communications link is then reestablished. You can facilitate dialback by using the \H option in the Systems file chat script at the place where dialback should occur. Include the \H as part of an expect string at the place where the dial-in server is expected to hang up. For example, suppose the chat script that calls a dial-in server contains the following string:INITIATED\Hogin:The UUCP dialing facility on the local machine expects to receive the characters, INITIATED, from the dial-in server. After the characters, INITIATED, have been matched, the dialing facility flushes any subsequent characters that the dialing facility receives until the dial-in server hangs up. The local dialing facility then waits until it receives the next part of the expect string, the characters ogin:, from the dial-in server. When it receives the ogin:, the dialing facility then continues through the chat script.A string of characters does not need to directly precede or follow the \H, as shown in the previous sample string. You can also use the pseudo-send STTY=value string to set modem characteristics. For instance, STTY=crtscts enables hardware flow control. STTY accepts all stty modes. See the stty1 and termio7I man pages for complete details.The following example enables hardware flow control in a Systems file entry: unix Any ACU 2400 12015551212 "" \r ogin: Puucp ssword:Passuan "" \ STTY=crtsctsThis pseudo-send string can also be used in entries in the Dialers file. In some situations, you have to reset the parity because the system that you are calling checks port parity and drops the line if it is wrong. The expect-send couplet, "" P_ZERO, sets the high-order bit (parity bit) to 0. See this expect-send couplet in the following example:unix Any ACU 2400 12015551212 "" P_ZERO "" \r ogin: Puucp ssword:PassuanThe following are parity couplets that can follow the expect-send couplet, "" P_ZERO:"" P_EVENSets the parity to even, which is the default "" P_ODDSets the parity to odd "" P_ONESets the parity bit to 1 These parity couplets can be inserted anywhere in the chat script. The parity couplets apply to all information in the chat script that follows "" P_ZERO, the expect-send couplet. A parity couplet can also be used in entries in the Dialers file. The following example includes the parity couplet, "" P_ONE:unix Any ACU 2400 12015551212 "" P_ZERO "" P_ONE "" \r ogin: Puucp ssword:Passuan The /etc/uucp/Devices file contains information for all the devices that can be used to establish a link to a remote computer. These devices include ACUs (which include high-speed modems), direct links, and network connections.An entry in the /etc/uucp/Devices file has the following syntax:Type Line Line2 Class Dialer-Token-PairsThe following is an entry in the Devices file for a U.S. Robotics V.32bis modem that is attached to port A and is running at 38,400 bps.ACUEC cua/a - 38400 usrv32bis-ecACUECEntry in the Type field. For more information, see Type Field in /etc/uucp/Devices File. cua/aEntry in the Line field. For more information, see Line Field in the /etc/uucp/Devices File. -Entry in the Line2 field. For more information, see Line2 Field in the /etc/uucp/Devices File. 38400Entry in the Class field. For more information, see Class Field in the /etc/uucp/Devices File. usrv32bis-ecEntry in the Dialer-Token-Pairs field. For more information, see Dialer-Token-Pairs Field in the /etc/uucp/Devices File. Each field is described in the next section. This field describes the type of link that the device establishes. The UUCP Type field can contain one of the keywords that is described in the sections that follow. The Direct keyword appears mainly in entries for cu connections. This keyword indicates that the link is a direct link to another computer or a port selector. Create a separate entry for each line that you want to reference through the -l option of cu. The ACU keyword indicates that the link to a remote computer (whether through cu, UUCP, asppp, or Solaris PPP 4.0) is made through a modem. This modem can be connected either directly to your computer or indirectly through a port selector. The port selector is a variable that is replaced in the Type field by the name of a port selector. Port selectors are devices that are attached to a network that prompts for the name of a calling modem, then grant access. The file /etc/uucp/Dialers contains caller scripts only for the micom and develcon port selectors. You can add your own port selector entries to the Dialers file. See UUCP /etc/uucp/Dialers File for more information. This variable is replaced by the name of a machine in the Type field, indicating that the link is a direct link to this particular computer. This naming scheme is used to associate the line in this Devices entry with an entry in /etc/uucp/Systems for the computer System-Name. Example 26–5 shows a comparison of the fields in /etc/uucp/Devices and the fields in /etc/uucp/Systems. The keyword that is used in the Type field of the Devices file is matched against the third field of the Systems file entries. In the Devices file, the Type field has the entry ACUEC, indicating an automatic call unit, in this instance a V.32bis modem. This value is matched against the Type field in the Systems file, which also contains the entry ACUEC. See UUCP /etc/uucp/Systems File for more information.The following is an example of an entry in the Devices file.ACUEC cua/a - 38400 usrv32bis-ecThe following is an example of an entry in the Systems file.Arabian Any ACUEC 38400 111222 ogin: Puucp ssword:beledi This field contains the device name of the line (known as port) that is associated with the Devices entry. If the modem that is associated with a particular entry were attached to the /dev/cua/a device (serial port A), the name that is entered in this field would be cua/a. An optional modem control flag, M, can be used in the Line field to indicate that the device should be opened without waiting for a carrier. For example:cua/a,M This field is a placeholder. Always use a hyphen (-) here. 801–type dialers, which are not supported in the Solaris OS, use the Line2 field. Non-801 dialers do not normally use this configuration, but still require a hyphen in this field. The Class field contains the speed of the device, if the keyword ACU or Direct is used in the Type field. However, the Class field can contain a letter and a speed, such as C1200 or D1200, to differentiate between classes of dialers, such as Centrex or Dimension PBX. This differentiation is necessary because many larger offices can have more than one type of telephone network. One network might be dedicated to serving only internal office communications while another network handles the external communications. In such a situation, you must distinguish which line or lines should be used for internal communications and which should be used for external communications. The keyword that is used in the Class field of the Devices file is matched against the Speed field of the Systems file. ACU cua/a - D2400 hayes Some devices can be used at any speed, so the keyword Any can be used in the Class field. If Any is used, the line matches any speed that is requested in the Speed field of the Systems file. If this field is Any and the Systems file Speed field is Any, the speed defaults to 2400 bps. The Dialer-Token-Pairs (DTP) field contains the name of a dialer and the token to pass it. The DTP field has this syntax:dialer token [dialer token]The dialer portion can be the name of a modem, a port monitor, or it can be direct or uudirect for a direct-link device. You can have any number of dialer-token pairs. If the dialer portion is not present, it is taken from a related entry in the Systems file. The token portion can be supplied immediately after the dialer portion. The last dialer-token pair might not be present, depending on the associated dialer. In most situations, the last pair contains only a dialer portion. The token portion is retrieved from the Phone field of the associated Systems file entry. A valid entry in the dialer portion can be defined in the Dialers file or can be one of several special dialer types. These special dialer types are compiled into the software and are therefore available without having entries in the Dialers file. The following list shows the special dialer types. TCPTCP/IP network TLITransport Level Interface Network (without STREAMS) TLISTransport Level Interface Network (with STREAMS) See Protocol Definitions in /etc/uucp/Devices File for more information. The DTP field can be structured four different ways, depending on the device that is associated with the entry. See the first way that the DTP field can be structured:Directly connected modem – If a modem is connected directly to a port on your computer, the DTP field of the associated Devices file entry has only one pair. This pair would normally be the name of the modem. This name is used to match the particular Devices file entry with an entry in the Dialers file. Therefore, the Dialer field must match the first field of a Dialers file entry.Dialers hayes =,-, "" \\dA\pTE1V1X1Q0S2=255S12=255\r\c \EATDT\T\r\c CONNECT Notice that only the dialer portion (hayes) is present in the DTP field of the Devices file entry. This means that the token to be passed on to the dialer (in this instance, the phone number) is taken from the Phone field of a Systems file entry. (\T is implied, as described in Example 26–9.) See the second and third ways that the DTP field can be structured:Direct link – For a direct link to a particular computer, the DTP field of the associated entry would contain the keyword direct. This condition is true for both types of direct-link entries, Direct and System-Name. Refer to Type Field in /etc/uucp/Devices File. Computers on the same port selector – If a computer with which you intend to communicate is on the same port selector switch as your computer, your computer must first access the switch. The switch then makes the connection to the other computer. This type of entry has only one pair. The dialer portion is used to match a Dialers file entry. Dialers develcon ,"" "" \pr\ps\c est:\007 \E\D\e \007 As shown, the token portion is left blank. This designation indicates that it is retrieved from the Systems file. The Systems file entry for this computer contains the token in the Phone field, which is normally reserved for the phone number of the computer. Refer to UUCP /etc/uucp/Systems File for details. This type of DTP contains an escape character (\D), which ensures that the content of the Phone field is not interpreted as a valid entry in the Dialcodes file. See the fourth way that the DTP field can be structured:Modems that are connected to port selector – If a high-speed modem is connected to a port selector, your computer must first access the port selector switch. The switch makes the connection to the modem. This type of entry requires two dialer-token-pairs. The dialer portion of each pair (the fifth and seventh fields of the entry) is used to match entries in the Dialers file, as follows. develcon "" "" \pr\ps\c est:\007 \E\D\e \007 ventel =&-% t"" \r\p\r\c $ <K\T%\r>\c ONLINE! In the first pair, develcon is the dialer and vent is the token that is passed to the Develcon switch to tell it which device, such as a Ventel modem, to connect to your computer. This token is unique for each port selector, as each switch can be set up differently. After the Ventel modem has been connected, the second pair is accessed. Ventel is the dialer and the token is retrieved from the Systems file. Two escape characters can appear in a DTP field: \T – Indicates that the Phone (token) field should be translated by using the /etc/uucp/Dialcodes file. This escape character is normally placed in the /etc/uucp/Dialers file for each caller script that is associated with a modem, such as Hayes, and U.S. Robotics. Therefore, the translation does not occur until the caller script is accessed. \D – Indicates that the Phone (token) field should not be translated by using the /etc/uucp/Dialcodes file. If no escape character is specified at the end of a Devices entry, the \D is assumed (default). A \D is also used in the /etc/uucp/Dialers file with entries that are associated with network switches develcon and micom. You can define the protocol to use with each device in /etc/uucp/Devices. This specification is usually unnecessary because you can use the default or define the protocol with the particular system you are calling. Refer to UUCP /etc/uucp/Systems File for details. If you do specify the protocol, you must use the following form:Type,Protocol [parameters]For example, you can use TCP,te to specify the TCP/IP protocol.The following table shows the available protocols for the Devices file. Protocol Description t This protocol is commonly used for transmissions over TCP/IP and other reliable connections. t assumes error-free transmissions. g This protocol is UUCP's native protocol. g is slow, reliable, and good for transmission over noisy telephone lines. e This protocol assumes transmission over error-free channels that are message oriented, as opposed to byte-stream oriented, such as TCP/IP. f This protocol is used for transmission over X.25 connections. f relies on flow control of the data stream and is meant for working over links that can (almost) be guaranteed to be error free, specifically X.25/PAD links. A checksum is enacted over a whole file only. If a transport fails, the receiver can request retransmission or retransmissions. Here is an example that shows a protocol designation for a device entry: TCP,te - - Any TCP - This example indicates that, for device TCP, you should try to use the t protocol. If the other end of the transmission refuses, use the e protocol. Neither e nor t is appropriate for use over modems. Even if the modem assures error-free transmission, data can still be dropped between the modem and the CPU. The /etc/uucp/Dialers file contains dialing instructions for commonly used modems. You probably do not need to change or add entries to this file unless you plan to use a nonstandard modem or plan to customize your UUCP environment. Nevertheless, you should understand what is in the file and how it relates to the Systems and Devices file. The text specifies the initial conversation that must occur on a line before the line can be made available for transferring data. This conversation, known as a chat script, is usually a sequence of ASCII strings that is transmitted and is expected. A chat script is often used to dial a phone number.As shown in the examples in UUCP /etc/uucp/Devices File, the fifth field in a Devices file entry is an index into the Dialers file or a special dialer type, such as TCP, TLI, or TLIS. The uucico daemon attempts to match the fifth field in the Devices file with the first field of each Dialers file entry. In addition, each odd-numbered Devices field, starting with the seventh position, is used as an index into the Dialers file. If the match succeeds, the Dialers entry is interpreted to perform the dialer conversation.Each entry in the Dialers file has the following syntax: dialer substitutions expect-sendThe following example shows the entry for a U.S. Robotics V.32bis modem.usrv32bis-e =,-, "" dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2&W\r\c OK\r \EATDT\T\r\c CONNECT\s14400/ARQ STTY=crtscts usrv32bis-eEntry in the Dialer field. The Dialer field matches the fifth and additional odd-numbered fields in the Devices file. =,-, ""Entry in the Substitutions field. The Substitutions field is a translation string. The first of each pair of characters is mapped to the second character in the pair. This mapping is usually used to translate = and - into whatever the dialer requires for “wait for dial tone” and “pause.” dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2&W\r\c OK\rEntry in Expect-Send field. The Expect-Send fields are character strings. \EATDT\T\r\c CONNECT\s14400/ARQ STTY=crtsctsMore of the Expect-Send field. The following example shows sample entries in the Dialers file, as distributed when you install UUCP as part of the Solaris installation program. penril =W-P "" \d > Q\c : \d- > s\p9\c )-W\p\r\ds\p9\c-) y\c : \E\TP > 9\c OK ventel =&-% "" \r\p\r\c $ <K\T%%\r>\c ONLINE! vadic =K-K "" \005\p *-\005\p-*\005\p-* D\p BER? \E\T\e \r\c LINE develcon "" "" \pr\ps\c est:\007 \E\D\e \n\007 micom "" "" \s\c NAME? \D\r\c GO hayes =,-, "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT # Telebit TrailBlazer tb1200 =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=2\r\c OK\r \EATDT\T\r\c CONNECT\s1200 tb2400 =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=3\r\c OK\r \EATDT\T\r\c CONNECT\s2400 tbfast =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=255\r\c OK\r \EATDT\T\r\c CONNECT\sFAST # USrobotics, Codes, and DSI modems dsi-ec =,-, "" \dA\pTE1V1X5Q0S2=255S12=255*E1*F3*M1*S1\r\c OK\r \EATDT\T\r\c CONNECT\sEC STTY=crtscts,crtsxoff dsi-nec =,-, "" \dA\pTE1V1X5Q0S2=255S12=255*E0*F3*M1*S1\r\c OK\r \EATDT\T\r\c CONNECT STTY=crtscts,crtsxoff usrv32bis-ec =,-, "" \dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2&W\r\c OK\r \EATDT\T\r\c CONNECT\s14400/ARQ STTY=crtscts,crtsxoff usrv32-nec =,-, "" \dA\pT&FE1V1X1Q0S2=255S12=255&A0&H1&M0&B0&W\r\c OK\r \EATDT\T\r\c CONNECT STTY=crtscts,crtsxoff codex-fast =,-, "" \dA\pT&C1&D2*MF0*AA1&R1&S1*DE15*FL3S2=255S7=40S10=40*TT5&W\r\c OK\r \EATDT\T\r\c CONNECT\s38400 STTY=crtscts,crtsxoff tb9600-ec =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=6\r\c OK\r \EATDT\T\r\cCONNECT\s9600 STTY=crtscts,crtsxoff tb9600-nec =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=6S180=0\r\c OK\r \EATDT\T\r\c CONNECT\s9600 STTY=crtscts,crtsxoff The following table lists escape characters that are commonly used in the send strings in the Dialers file. Character Description \b Sends or expects a backspace character. \c No newline or carriage return. \d Delays for approximately 2 seconds. \D Phone number or token without Dialcodes translation. \e Disables echo checking. \E Enables echo checking for slow devices. \K Inserts a Break character. \n Sends newline. \nnn Sends octal number. Additional escape characters that can be used are listed in the section UUCP /etc/uucp/Systems File. \N Sends or expects a NULL character (ASCII NUL). \p Pauses for approximately 12–14 seconds. \r Returns. \s Sends or expects a space character. \T Phone number or token with Dialcodes translation. Here is a penril entry in the Dialers file: penril =W-P "" \d > Q\c : \d- > s\p9\c )-W\p\r\ds\p9\c-) y\c : \E\TP > 9\c OK First, the substitution mechanism for the phone number argument is established so that any = is replaced with a W (wait for dial tone) and any - with a P (pause). The handshake that is given by the remainder of the line works as listed:"" – Waits for nothing, which means proceed to the next step. \d – Delays 2 seconds, then sends a carriage return. > – Waits for a >. Q\c – Sends a Q without a carriage return. : – Expects a :. \d- – Delays 2 seconds, sends a - and a carriage return. > – Waits for a >. s\p9\c – Sends an s, pauses, sends a 9 with no carriage return. )-W\p\r\ds\p9\c-) – Waits for a ). If ) is not received, processes the string between the - characters as follows. Sends a W, pauses, sends a carriage return, delays, sends an s, pauses, sends a 9 without a carriage return, then waits for the ). y\c – Sends a y with no carriage return. : – Waits for a :. \E\TP – \E enables echo checking. From this point forward, whenever a character is transmitted, UUCP waits for the character to be received before proceeding. Then, UUCP sends the phone number. The \T means to take the phone number that is passed as an argument. The \T applies the Dialcodes translation and the modem function translation that is specified by field 2 of this entry. Then \T sends a P and a carriage return. > – Waits for a >. 9\c – Sends a 9 without a newline. OK – Waits for the string OK. You can also use the pseudo-send STTY=value string to set modem characteristics. For instance, STTY=crtscts enables outbound hardware flow control. STTY=crtsxoff enables inbound hardware flow control. STTY=crtscts,crtsxoff enables both outbound and inbound hardware flow control. STTY accepts all the stty modes. See the stty1 and termio7I man pages.The following example would enable hardware flow control in a Dialers entry:dsi =,–, "" \dA\pTE1V1X5Q0S2=255S12=255*E1*F3*M1*S1\r\c OK\r \EATDT\T\r\c CONNECT\sEC STTY=crtscts This pseudo-send string can also be used in entries in the Systems file. In some situations, you have to reset the parity because the system that you are calling checks port parity and drops the line if it is wrong. The expect-send couplet P_ZERO sets parity to zero: foo =,-, "" P_ZERO "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r\EATDT\T\r\c CONNECT The following are parity couplets that can follow the expect-send couplet:"" P_EVENSets the parity to even, which is the default "" P_ODDSets the parity to odd "" P_ONESets the parity to one This pseudo-send string can also be used in entries in the Systems file. You can use files in this section in addition to the Systems, Devices, and Dialers file when doing basic UUCP configuration. The /etc/uucp/Dialcodes file enables you to define dial-code abbreviations that can be used in the Phone field in the /etc/uucp/Systems file. You can use the Dialcodes file to provide additional information about a basic phone number that is used by several systems at the same site. Each entry has the following syntax:Abbreviation Dial-SequenceAbbreviationThis field provides the abbreviation that is used in the Phone field of the Systems file. Dial-SequenceThis field provides the dial sequence that is passed to the dialer when that particular Systems file entry is accessed. Compare the fields in the two files. The following are the fields in the Dialcodes file.Abbreviation Dial-SequenceThe following are the fields in the Systems file.System-Name Time Type Speed Phone Chat ScriptThe following table contains sample content for the fields in a Dialcodes file. Abbreviation Dial-Sequence NY 1=212 jt 9+847 In the first row, NY is the abbreviation to appear in the Phone field of the Systems file. For example, the Systems file might have the following entry:NY5551212When uucico reads NY in the Systems file, uucico searches the Dialcodes file for NY and obtains the dialing sequence 1=212. 1=212 is the dialing sequence that is needed for any phone call to New York City. This sequence includes the number 1, an “equal sign” (=) meaning pause and wait for a secondary dial tone, and the area code 212. uucico sends this information to the dialer, then returns to the Systems file for the remainder of the phone number, 5551212. The entry jt 9=847- would work with a Phone field such as jt7867 in the Systems file. When uucico reads the entry that contains jt7867 in the Systems file, uucico sends the sequence 9=847-7867 to the dialer, if the token in the dialer-token pair is \T. The /etc/uucp/Sysfiles file lets you assign different files to be used by uucp and cu as Systems, Devices, and Dialers files. For more information about cu, see the cu1C man page. You can use Sysfiles for the following: Different Systems files so that requests for login services can be made to different addresses than uucp services. Different Dialers files so that you can assign different handshaking for cu and uucp. Multiple Systems, Dialers, and Devices files. The Systems file in particular can become large, making the file more convenient to split into several smaller files. The syntax of the Sysfiles file is as follows: service=w systems=x:x dialers=y:y devices=z:z wRepresents uucico, cu, or both commands separated by a colon xRepresents one or more files to be used as the Systems file, with each file name separated by a colon and read in the order that it is presented yRepresents one or more files to be used as the Dialers file zRepresents one or more files to be used as the Devices file Each file name is assumed to be relative to the /etc/uucp directory unless a full path is given. The following sample, /etc/uucp/Sysfiles, defines a local Systems file (Local_Systems) in addition to the standard /etc/uucp/Systems file: service=uucico:cu systems=Systems :Local_Systems When this entry is in /etc/uucp/Sysfiles, both uucico and cu first check in the standard /etc/uucp/Systems. If the system being called does not have an entry in that file, or if the entries in the file fail, then both commands check /etc/uucp/Local_Systems. As specified in the previous entry, cu and uucico share the Dialers and Devices files. When different Systems files are defined for uucico and cu services, your machine stores two different lists of Systems. You can print the uucico list by using the uuname command or the cu list by using the uuname C command. The following is another example of the file, which shows that the alternate files are consulted first and the default files are consulted if necessary: service=uucico systems=Systems.cico:Systems dialers=Dialers.cico:Dialers \ devices=Devices.cico:Devices service=cu systems=Systems.cu:Systems \ dialers=Dialers.cu:Dialers \ devices=Devices.cu:Devices Every machine that uses UUCP must have an identifying name, often referred to as the node name. The node name appears in the remote machine's /etc/uucp/Systems file, along with the chat script and other identifying information. Normally, UUCP uses the same node name as is returned by the uname -n command, which is also used by TCP/IP. You can specify a UUCP node name independent of the TCP/IP host name by creating the /etc/uucp/Sysname file. The file has a one-line entry that contains the UUCP node name for your system. The /etc/uucp/Permissions file specifies the permissions that remote computers have for login, file access, and command execution. Some options restrict the remote computer's ability to request files and its ability to receive files that are queued by the local machine. Another option is available that specifies the commands that a remote machine can execute on the local computer. Each entry is a logical line, with physical lines terminated by a backslash (\) to indicate continuation. Entries are composed of options that are delimited by a blank space. Each option is a name-value pair in the following format: name=value Values can be colon-separated lists. No blank space is allowed within an option assignment. Comment lines begin with a pound sign (#) and occupy the entire line up to a newline character. Blank lines are ignored, even within multiple-line entries. The types of Permissions file entries are as follows: LOGNAME – Specifies the permissions that become effective when a remote computer logs in to (calls) your computer. When a remote machine calls you, its identity is questionable unless the remote machine has a unique login and verifiable password. MACHINE – Specifies permissions that become effective when your computer logs in to (calls) a remote computer. LOGNAME entries contain a LOGNAME option. MACHINE entries contain a MACHINE option. One entry can contain both options. When using the Permissions file to restrict the level of access that is granted to remote computers, you should consider the following: All login IDs that are used by remote computers to log in for UUCP communications must appear in one and only one LOGNAME entry. Any site that is called with a name that does not appear in a MACHINE entry has the following default permissions or restrictions: Local send-and-receive requests are executed. The remote computer can send files to your computer's /var/spool/uucppublic directory. The commands that are sent by the remote computer for execution on your computer must be one of the default commands, usually rmail. When a remote computer calls your computer and requests to receive a file, this request can be granted or be denied. The REQUEST option specifies whether the remote computer can request to set up file transfers from your computer. The string REQUEST=yes specifies that the remote computer can request to transfer files from your computer. The string REQUEST=no specifies that the remote computer cannot request to receive files from your computer. REQUEST=no, the default value, is used if the REQUEST option is not specified. The REQUEST option can appear in either a LOGNAME entry, so that the remote computer calls you, or a MACHINE entry, so that you call the remote computer. When a remote computer calls your computer and completes its work, the remote computer can attempt to retrieve the work that your computer has queued for it. The SENDFILES option specifies whether your computer can send the work that is queued for the remote computer. The string SENDFILES=yes specifies that your computer can send the work that is queued for the remote computer if it is logged in as one of the names in the LOGNAME option. This string is mandatory if you have entered Never in the Time field of /etc/uucp/Systems. This designation sets up your local machine in passive mode, but it is not allowed to initiate a call to this particular remote computer. See UUCP /etc/uucp/Systems File for more information. The string SENDFILES=call specifies that files that are queued in your computer are sent only when your computer calls the remote computer. The call value is the default for the SENDFILES option. This option is only significant in LOGNAME entries because MACHINE entries apply when calls are sent to remote computers. If the option is used with a MACHINE entry, the option is ignored. This option enables you to designate a unique UUCP node name for your computer in addition to its TCP/IP host name, as returned by the hostname command. For instance, if you have unknowingly given your host the same name as that of some other system, you can set the MYNAME option of the Permissions file. Suppose that you want your organization to be known as widget. If all your modems are connected to a machine with the host name gadget, you can have an entry in gadget's Permissions file that reads as follows: service=uucico systems=Systems.cico:Systems dialers=Dialers.cico:Dialers \ devices=Devices.cico:Devices service=cu systems=Systems.cu:Systems \ dialers=Dialers.cu:Dialers \ devices=Devices.cu:DevicesNow, the system world can log in to the machine gadget as if it were logging in to widget. In order for machine world to know you also by the aliased name widget when you call it, you can have an entry that reads as follows:MACHINE=world MYNAME=widgetYou can also use the MYNAME option for testing purposes, as this option allows your machine to call itself. However, because this option could be used to mask the real identity of a machine, you should use the VALIDATE option, as described in UUCP VALIDATE Option. These options specify the various parts of the file system that uucico can read from or write to. You can designate READ and WRITE options with either MACHINE or LOGNAME entries. The default for both the READ and WRITE options is the uucppublic directory, as shown in the following strings: READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic The strings READ=/ and WRITE=/ specify permission to access any file that can be accessed by a local user with Other permissions. The value of these entries is a colon-separated list of path names. The READ option is for requesting files, and the WRITE option is for depositing files. One of the values must be the prefix of any full path name of a file entering or exiting. To grant permission to deposit files in /usr/news as well as in the public directory, use the following values with the WRITE option: WRITE=/var/spool/uucppublic:/usr/news If the READ and WRITE options are used, all path names must be specified because the path names are not added to the default list. For instance, if the /usr/news path name were the only path specified in a WRITE option, permission to deposit files in the public directory would be denied. Be careful which directories you make accessible for reading and writing by remote systems. For example, the /etc directory contains many critical system files. Remote users should not have permission to deposit files in this directory. The NOREAD and NOWRITE options specify exceptions to the READ and WRITE options or defaults. The following entry permits reading any file except those files in the /etc directory (and its subdirectories) Remember, these options are prefixes. READ=/ NOREAD=/etc WRITE=/var/spool/uucppublic This entry permits writing only to the default /var/spool/uucppublic directory. NOWRITE works in the same manner as the NOREAD option. You can use the NOREAD and NOWRITE options in both LOGNAME and MACHINE entries. You can use the CALLBACK option in LOGNAME entries to specify that no transaction occurs until the calling system is called back. The reasons to set up CALLBACK are as follows: For security purposes – If you call back a machine, you can be sure it is the right machine. For accounting purposes – If you are doing long data transmissions, you can choose the machine that is billed for the longer call. The string CALLBACK=yes specifies that your computer must call back the remote computer before any file transfers can occur. The default for the CALLBACK option is CALLBACK=no. If you set CALLBACK to yes, the permissions that affect the rest of the conversation must be specified in the MACHINE entry that corresponds to the caller. Do not specify these permissions in the LOGNAME, or in the LOGNAME entry that the remote machine might have set for your host. If two sites have the CALLBACK option set for each other, a conversation never is started. The COMMANDS option can compromise the security of your system. Use this option with extreme care. You can use the COMMANDS option in MACHINE entries to specify the commands that a remote computer can execute on your machine. The uux program generates remote execution requests and queues the requests to be transferred to the remote computer. Files and commands are sent to the target computer for remote execution, which is an exception to the rule that MACHINE entries apply only when your system calls out. Note that COMMANDS is not used in a LOGNAME entry. COMMANDS in MACHINE entries defines command permissions, whether you call the remote system or the remote system calls you. The string COMMANDS=rmail specifies the default commands that a remote computer can execute on your computer. If a command string is used in a MACHINE entry, the default commands are overridden. For instance, the following entry overrides the COMMAND default so that the computers that are named owl, raven, hawk, and dove can now execute rmail, rnews, and lp on your computer. MACHINE=owl:raven:hawk:dove COMMANDS=rmail:rnews:lp In addition to the names as just specified,you can have full path names of commands. For example, the following entry specifies that command rmail uses the default search path.COMMANDS=rmail:/usr/local/rnews:/usr/local/lp The default search path for UUCP is /bin and /usr/bin. When the remote computer specifies rnews or /usr/local/rnews for the command to be executed, /usr/local/rnews is executed regardless of the default path. Likewise, /usr/local/lp is the lp command that is executed. Including the ALL value in the list means that any command from the remote computers that are specified in the entry is executed. If you use this value, you give the remote computers full access to your machine.This value allows far more access than normal users have. You should use this value only when both machines are at the same site, are closely connected, and the users are trusted. Here is the string with the ALL value added:COMMANDS=/usr/local/rnews:ALL:/usr/local/lp This string illustrates two points:The ALL value can appear anywhere in the string. The path names that are specified for rnews and lp are used (instead of the default) if the requested command does not contain the full path names for rnews or lp. You should use the VALIDATE option whenever you specify potentially dangerous commands, such as cat and uucp with the COMMANDS option. Any command that reads or writes files is potentially dangerous to local security when the command is executed by the UUCP remote execution daemon (uuxqt). Use the VALIDATE option in conjunction with the COMMANDS option whenever you specify commands that are potentially dangerous to your machine's security. VALIDATE is merely an added level of security on top of the COMMANDS option, though it is a more secure way to open command access than ALL. VALIDATE provides a certain degree of verification of the caller's identity by cross-checking the host name of a calling machine against the login name it uses. The following string ensures that if any machine other than widget or gadget tries to log in as Uwidget, the connection is refused.LOGNAME=Uwidget VALIDATE=widget:gadget The VALIDATE option requires privileged computers to have a unique login and password for UUCP transactions. An important aspect of this validation is that the login and password that are associated with this entry are protected. If an outsider obtains that information, that particular VALIDATE option can no longer be considered secure. Carefully consider which remote computers you are granting privileged logins and passwords for UUCP transactions. Giving a remote computer a special login and password with file access and remote execution capability is like giving anyone on that computer a normal login and password on your computer. Therefore, if you cannot trust someone on the remote computer, do not provide that computer with a privileged login and password. The following LOGNAME entry specifies that if one of the remote computers that claims to be eagle, owl, or hawk logs in on your computer, it must have used the login uucpfriend:LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk If an outsider obtains the uucpfriend login and password, masquerading is easy. But what does this entry have to do with the COMMANDS option, which appears only in MACHINE entries? This entry links the MACHINE entry (and COMMANDS option) with a LOGNAME entry that is associated with a privileged login. This link is needed because the execution daemon is not running while the remote computer is logged in. Actually, the link is an asynchronous process that does not know which computer sent the execution request. Therefore, the real question is: How does your computer know where the execution files came from? Each remote computer has its own spool directory on your local machine. These spool directories have write permission that is given only to the UUCP programs. The execution files from the remote computer are put in its spool directory after being transferred to your computer. When the uuxqt daemon runs, it can use the spool directory name to find the MACHINE entry in the Permissions file and get the COMMANDS list. Or, if the computer name does not appear in the Permissions file, the default list is used. This example shows the relationship between the MACHINE and LOGNAME entries: MACHINE=eagle:owl:hawk REQUEST=yes \ COMMANDS=rmail:/usr/local/rnews \ READ=/ WRITE=/ LOGNAME=uucpz VALIDATE=eagle:owl:hawk \ REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/ The value in the COMMANDS option means that remote users can execute rmail and /usr/local/rnews. In the first entry, you must assume that when you want to call one of the computers that is listed, you are really calling either eagle, owl, or hawk. Therefore, any files that are put into one of the eagle, owl, or hawk spool directories is put there by one of those computers. If a remote computer logs in and says that it is one of these three computers, its execution files are also put in the privileged spool directory. You therefore have to validate that the computer has the privileged login uucpz. You might want to specify different option values for remote machines that are not mentioned in specific MACHINE entries. The need might arise when many computers are calling your host, and the command set changes from time to time. The name OTHER for the computer name is used for this entry as shown in this example: MACHINE=OTHER \ COMMANDS=rmail:rnews:/usr/local/Photo:/usr/local/xp All other options that are available for the MACHINE entry can also be set for the computers that are not mentioned in other MACHINE entries. You can combine MACHINE and LOGNAME entries into a single entry when the common options are the same. For example, the two sets of entries that follow share the same REQUEST, READ, and WRITE options:MACHINE=eagle:owl:hawk REQUEST=yes \ READ=/ WRITE=/andLOGNAME=uupz REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/You can merge these entries, as shown:MACHINE=eagle:owl:hawk REQUEST=yes \ logname=uucpz SENDFILES-yes \ READ=/ WRITE=/Combining MACHINE and LOGNAME entries makes the Permissions file more manageable and efficient. When sending files through a series of machines, the intermediary machines must have the command uucp among their COMMANDS options. If you type the following command, the forwarding operation works only if machine willow permits machine oak to execute the uucp program. % uucp sample.txt oak\!willow\!pine\!/usr/spool/uucppublicThe machine oak also must permit your machine to execute the uucp program. The machine pine, as the last machine designated, does not have to permit the uucp command because the machine is not doing any forwarding operations. Machines are not normally set up this way. The /etc/uucp/Poll file contains information for polling remote computers. Each entry in the Poll file contains the name of a remote computer to call, followed by a tab character or a space, and finally the hours the computer should be called. The format of entries in the Poll file are as follows:sys-name hour ... For example, the entry eagle 0 4 8 12 16 20 provides polling of computer eagle every four hours.The uudemon.poll script processes the Poll file but does not actually perform the poll. The script merely sets up a polling work file (always named C.file) in the spool directory. The uudemon.poll script starts the scheduler, and the scheduler examines all work files in the spool directory. The /etc/uucp/Config file enables you to override certain parameters manually. Each entry in the Config file has this format: parameter=valueSee the Config file that is provided with your system for a complete list of configurable parameter names. The following Config entry sets the default protocol ordering to Gge and changes the G protocol defaults to 7 windows and 512-byte packets.Protocol=G(7,512)ge The /etc/uucp/Grades file contains the definitions for the job grades that can be used to queue jobs to a remote computer. This file also contains the permissions for each job grade. Each entry in this file represents a definition of an administrator-defined job grade that lets users queue jobs. Each entry in the Grades file has the following format:User-job-grade System-job-grade Job-size Permit-type ID-listEach entry contains fields that are separated by a blank space. The last field in the entry is composed of subfields that are also separated by spaces. If an entry occupies more than one physical line, you can use a backslash to continue the entry onto the following line. Comment lines begin with a pound sign (#) and occupy the entire line. Blank lines are always ignored. This field contains an administrator-defined user-job-grade name of up to 64 characters. This field contains a single-character job grade to which User-job-grade is mapped. The valid list of characters is A–Z, a–z, with A having the highest priority and z the lowest. The user job grade can be bound to more than one system job grade. Note that the Grades file is searched sequentially for occurrences of a user job grade. Therefore, any multiple occurrences of a system job grade should be listed in compliance with the restriction on the maximum job size. While no maximum number exists for the user job grades, the maximum number of system job grades that are allowed is 52. The reason is that more than one User-job-grade can be mapped to a System-job-grade, but each User-job-grade must be on a separate line in the file. Here is an example:mail N Any User Any netnews N Any User Any If this configuration is in a Grades file, these two User-job-grade fields share the same System-job-grade. Because the permissions for a Job-grade are associated with a User-job-grade and not a System-job-grade, two User-job-grades can share the same System-job-grades and have two different sets of permissions. You can define the binding of a default User-job-grade to a system job grade. You must use the keyword default as the user job grade in the User-job-grade field of the Grades file and the system job grade that it is bound to. The Restrictions and ID fields should be defined as Any so that any user and any size job can be queued to this grade. Here is an example: default a Any User Any If you do not define the default user job grade, the built-in default grade Z is used. Because the restriction field default is Any, multiple occurrences of the default grade are not checked. This field specifies the maximum job size that can be entered in the queue. Job-size is measured in bytes and can be a list of the options that are described in the following list. nnnnInteger that specifies the maximum job size for this job grade nKDecimal number that represents the number of kilobytes (K is an abbreviation for kilobyte) nMDecimal number that represents the number of megabytes (M is an abbreviation for megabyte) AnyKeyword that specifies that no maximum job size exists Here are some examples:5000 represents 5000 bytes 10K represents 10 Kbytes 2M represents 2 Mbytes This field contains a keyword that denotes how to interpret the ID list. The following table lists the keywords and their meanings. Keyword ID List Contents User Login names of users who are permitted to use this job grade Non-user Login names of users who are not permitted to use this job grade Group Group names whose members are permitted to use this group Non-group Group names whose members are not permitted to use this job grade This field contains a list of login names or group names that are to be permitted or denied queuing to this job grade. The list of names are separated by a blank space and terminated by a newline character. The keyword Any is used to denote that anyone is permitted to queue to this job grade. This section describes three less-frequently modified files that impact the use of UUCP facilities. The /etc/uucp/Devconfig file enables you to configure devices by service, such as uucp or cu. Devconfig entries define the STREAMS modules that are used for a particular device. These entries have the following format:service=x device=y push=z[:z...]x can be cu, uucico, or both services separated by a colon. y is the name of a network and must match an entry in the Devices file. z is replaced by the names of STREAMS modules in the order that they are to be pushed onto the Stream. Different modules and devices can be defined for cu and uucp services. The following entries are for a STARLAN network and would most commonly be used in the file: service=cu device=STARLAN push=ntty:tirdwr service=uucico device=STARLAN push=ntty:tirdwr This example pushes ntty, then tirdwr. The /etc/uucp/Limits file controls the maximum number of simultaneous uucicos, uuxqts, and uuscheds that are running in the uucp networking. In most situations, the default values are acceptable and no changes are needed. If you want to change them, however, use any text editor. The format of the Limits file is as follows: service=x max=y:x can be uucico, uuxqt or uusched, and y is the limit that is permitted for that service. The fields can be in any order and in lowercase. The following entries should most commonly be used in the Limits file: service=uucico max=5 service=uuxqt max=5 service=uusched max=2 The example allows five uucicos, five uuxqts, and two uuscheds to run on your machine. The other file that affects the use of communication facilities is the remote.unknown file. This file is a binary program that executes when a machine that is not found when any of the Systems files starts a conversation. This program logs the conversation attempt and drops the connection. If you change the permissions of the remote.unknown file so that the file cannot execute, your system accepts connections from any system. This program executes when a machine that is not in any of the Systems starts a conversation. The program logs the conversation attempt but fails to make a connection. If you change the permissions of this file so that the file cannot execute (chmod 000 remote.unknown), your system accepts any conversation requests. This change is not trivial. You should have good reasons for making this change. The UUCP administrative files are described next. These files are created in spool directories to lock devices, hold temporary data, or keep information about remote transfers or executions. Temporary data files (TM) – These data files are created by UUCP processes under the spool directory /var/spool/uucp/x when a file is received from another computer. The directory x has the same name as the remote computer that is sending the file. The names of the temporary data files have the following format: TM.pid.ddd pid is a process ID and ddd is a sequential three-digit number that starts at 0. When the entire file is received, the TM.pid.ddd file is moved to the path name that is specified in the C.sysnxxxx file (discussed subsequently) that caused the transmission. If processing is abnormally terminated, the TM.pid.ddd file can remain in the x directory. These files should be automatically removed by uucleanup. Lock files (LCK) – Lock files are created in the /var/spool/locks directory for each device in use. Lock files prevent duplicate conversations and multiple attempts to use the same calling device. The following table shows the different types of UUCP lock files. File Name Description LCK.sys sys represents the name of the computer that is using the file LCK.dev dev represents the name of a device that is using the file LCK.LOG LOG represents a locked UUCP log file These files can remain in the spool directory if the communications link is unexpectedly dropped, such as when a computer crashes. The lock file is ignored (removed) after the parent process is no longer active. The lock file contains the process ID of the process that created the lock.Work file (C.) – Work files are created in a spool directory when work, such as file transfers or remote command executions, has been queued for a remote computer. The names of work files have the following format: C.sysnxxxxsys is the name of the remote computer, n is the ASCII character that represents the grade (priority) of the work, and xxxx is the four-digit job sequence number that is assigned by UUCP. Work files contain the following information: Full path name of the file to be sent or be requested. Full path name of the destination or user or file name. User login name. List of options. Name of associated data files in the spool directory. If the uucp C or uuto p option was specified, a dummy name (D.0) is used. Mode bits of the source file. Remote user's login name to be notified on completion of the transfer. Data file(D.) – Data files are created when you specify on the command line to copy the source file to the spool directory. The names of data files have the following format: D.systmxxxxyyy – systm is the first five characters in the name of the remote computer. xxxx is a four-digit job sequence number assigned by uucp. The four-digit job sequence number can be followed by a subsequent number. yyy is used when several D. files are created for a work (C.) file. X. (execute file) – Execute files are created in the spool directory prior to remote command executions. The names of execute files have the following format: X.sysnxxxx sys is the name of the remote computer. n is the character that represents the grade (priority) of the work. xxxx is a four-digit sequence number that is assigned by UUCP. Execute files contain the following information: Requester's login and computer name Names of files that are required for execution Input to be used as the standard input to the command string Computer and file name to receive standard output from the command execution Command string Option lines for return status requests This section lists the error messages that are associated with UUCP. The following table lists ASSERT error messages. Error Message Description or Action CAN'T OPEN An open or fopen failed. CAN'T WRITE A write, fwrite, fprint, or similar command, failed. CAN'T READ A read, fgets, or similar command failed. CAN'T CREATE A creat call failed. CAN'T ALLOCATE A dynamic allocation failed. CAN'T LOCK An attempt to make a LCK (lock) file failed. In some situations, this error is fatal. CAN'T STAT A stat call failed. CAN'T CHMOD A chmod call failed. CAN'T LINK A link call failed. CAN'T CHDIR A chdir call failed. CAN'T UNLINK An unlink call failed. WRONG ROLE This is an internal logic problem. CAN'T MOVE TO CORRUPTDIR An attempt to move some bad C. or X. files to the /var/spool/uucp/.Corrupt directory failed. The directory is probably missing or has wrong modes or owner. CAN'T CLOSE A close or fclose call failed. FILE EXISTS The creation of a C. or D. file is attempted, but the file exists. This error occurs when a problem arises with the sequence file access, which usually indicates a software error. NO uucp SERVICE NUMBER A TCP/IP call is attempted, but no entry is in /etc/services for UUCP. BAD UID The user ID is not in the password database. Check name service configuration. BAD LOGIN_UID Same as previous description. BAD LINE A bad line is in the Devices file. Not enough arguments on one or more lines. SYSLST OVERFLOW An internal table in gename.c overflowed. A single job attempted to talk to more than 30 systems. TOO MANY SAVED C FILES Same as previous description. RETURN FROM fixline ioctl An ioctl(2), which should never fail, failed. A system driver problem has occurred. BAD SPEED A bad line speed appears in the Devices or Systems file (Class or Speed field). BAD OPTION A bad line or option is in the Permissions file. This error must be fixed immediately. PKCGET READ The remote machine probably hung up. No action is needed. PKXSTART The remote machine aborted in a nonrecoverable way. This error can usually be ignored. TOO MANY LOCKS An internal problem has occurred. Contact your system vendor. XMV ERROR A problem with some file or directory has occurred. The spool directory is the probable cause, as the modes of the destinations were supposed to be checked before this process was attempted. CAN'T FORK An attempt to make a fork and exec failed. The current job should not be lost but will be attempted later (uuxqt). No action is needed. The following table is a list of the most common STATUS error messages. Error Message Description/Action OK Status is acceptable. NO DEVICES AVAILABLE Currently no device is available for the call. Check whether a valid device is in the Devices file for the particular system. Check the Systems file for the device to be used to call the system. WRONG TIME TO CALL A call was placed to the system at a time other than what is specified in the Systems file. TALKING Self-explanatory. LOGIN FAILED The login for the particular machine failed. The cause could be a wrong login or password, wrong number, a slow machine, or failure in executing the Dialer-Token-Pairs script. CONVERSATION FAILED The conversation failed after successful startup. This error usually means that one side went down, the program aborted, or the line (link) was dropped. DIAL FAILED The remote machine never answered. The cause could be a bad dialer or the wrong phone number. BAD LOGIN/MACHINE COMBINATION The machine called with a login/machine name that does not agree with the Permissions file. This error could be an attempt to masquerade. DEVICE LOCKED The calling device to be used is currently locked and in use by another process. ASSERT ERROR An ASSERT error occurred. Check the /var/uucp/.Admin/errors file for the error message and refer to the section UUCP ASSERT Error Messages. SYSTEM NOT IN Systems FILE The system is not in the Systems file. CAN'T ACCESS DEVICE The device tried does not exist or the modes are wrong. Check the appropriate entries in the Systems and Devices files. DEVICE FAILED The device could not be opened. WRONG MACHINE NAME The called machine is reporting a different name than expected. CALLBACK REQUIRED The called machine requires that it call your machine. REMOTE HAS A LCK FILE FOR ME The remote machine has a LCK file for your machine. The remote machine could be trying to call your machine. If the remote machine has an older version of UUCP, the process that was talking to your machine might have failed, leaving the LCK file. If the remote machine has the new version of UUCP and is not communicating with your machine, the process that has a LCK file is hung. REMOTE DOES NOT KNOW ME The remote machine does not have the node name of your machine in its Systems file. REMOTE REJECT AFTER LOGIN The login that was used by your machine to log in does not agree with what the remote machine was expecting. REMOTE REJECT, UNKNOWN MESSAGE The remote machine rejected the communication with your machine for an unknown reason. The remote machine might not be running a standard version of UUCP. STARTUP FAILED Login succeeded, but initial handshake failed. CALLER SCRIPT FAILED This error is usually the same as DIAL FAILED. However, if this error occurs often, suspect the caller script in the Dialers file. Use Uutry to check. The following table lists the exit code numbers of error status messages that are produced by the /usr/include/sysexits.h file. Not all are currently used by uucp. Message Number Description Meaning 64 Base Value for Error Messages Error messages begin at this value. 64 Command–Line Usage Error The command was used incorrectly, for example, with the wrong number of arguments, a bad flag, or a bad syntax. 65 Data Format Error The input data was incorrect in some way. This data format should only be used for user's data and not system files. 66 Cannot Open Input An input file, not a system file, did not exist, or was not readable. This problem could also include errors like “No message” to a mailer. 67 Address Unknown The user that was specified did not exist. This error might be used for mail addresses or remote logins. 68 Host Name Unknown The host did not exist. This error is used in mail addresses or network requests. 69 Service Unavailable A service is unavailable. This error can occur if a support program or file does not exist. This message also can simply indicate that something does not work and the cause currently is not identifiable. 70 Internal Software Error An internal software error has been detected. This error should be limited to non-operating system-related errors, if possible. 71 System Error An operating system error has been detected. This error is intended to be used for conditions like “cannot fork”, “cannot create pipe.” For instance, this error includes a getuid return of a user who does not exist in the passwd file. 72 Critical OS File Missing A system file such as /etc/passwd or /var/admin/utmpx does not exist, cannot be opened, or has an error, such as a syntax error. 73 Can't Create Output File A user-specified output file cannot be created. 74 Input/Output Error An error occurred while doing I/O on some file. 75 Temporary Failure. User is invited to retry Temporary failure that is not really an error. In sendmail, this means that a mailer, for example, could not create a connection, and the request should be reattempted later. 76 Remote Error in Protocol The remote system returned something that was “not possible” during a protocol exchange. 77 Permission Denied You do not have sufficient permission to perform the operation. This message is not intended for file system problems, which should use NOINPUT or CANTCREAT, but rather for higher-level permissions. For example, kre uses this message to restrict students who can send mail to. 78 Configuration Error The system detected an error in the configuration. 79 Entry Not Found Entry not found. 79 Maximum Listed Value Highest value for error messages.