Before you start writing the UUCP configuration files, you have to gather some information it needs to know.
First, you will have to figure out what serial device your modem is attached to. Usually, the (DOS) ports COM1 through COM4 map to the device special files /dev/cua0 through /dev/cua3. Most distributions, such as Slackware, create a link /dev/modem as a link to the appropriate cua* device file, and configure kermit, seyon, etc, to use this generic file. In this case, you should either use /dev/modem in your UUCP configuration, too.
The reason for this is that all dial-out programs use so-called lock files to signal when a serial port is in use. The names of these lock files are a concatenation of the string LCK.. and the device file name, for instance LCK..cua1. If programs use different names for the same device, they will fail to recognize each other's lock files. As a consequence, they will disrupt each other's session when started at the same time. This is not an unlikely event when you schedule your UUCP calls using a crontab entry.
For details of setting up your serial ports, please refer to chapter-.
Next, you must find out at what speed your modem and will communicate. You will have to set this to the maximum effective transfer rate you expect to get. The effective transfer rate may be much higher than the raw physical transfer rate your modem is capable of. For instance, many modems send and receive data at 2400bps (bits per second). Using compression protocols such as V.42bis, the actual transfer rate may climb up to 9600bps.
Of course, if UUCP is to do anything, you will need the phone number of a system to call. Also, you will need a valid login id and possibly a password for the remote machine.
You will also have to know exactly how to log into the system. E.g., do you have to press the BREAK key before the login prompt appears? Does it display login: or user:? This is necessary for composing the chat script, which is a recipe telling uucico how to log in. If you don't know, or if the usual chat script fails, try to call the system with a terminal program like kermit or minicom, and write down exactly what you have to do.