system  sched  device_type  speed  phone  chat_script

sys2 Any TCP - sys2.kgn.ibm.com  in:--in: nuucp ssword: uupasswd

system

The name of a remote system. This name must be unique (compared to other remote system names in the Systems file) in its first seven characters.

sched

The times when your local system is permitted to call system. There are four subfields in the sched field: day, time, grade, and retry.

An example sched field looks like this:

Mo1200/C;5

where Mo is the day subfield, 1200 is the time subfield, /C is the grade subfield, and 5 is the retry subfield.

The description of each subfield follows:

day

Indicates which days of the week your system can call the remote system named by system. The abbreviations Mo, Tu, We, Th, Fr, Sa, and Su represent individual days. You can also use the following keywords:

Any

Your system can call the remote system on any day.

Never

Your system should never call the remote system. It should only wait to be called.

Wk

Your system can call the remote system on any weekday (that is, Monday-Friday).

time

The range of times during which your system can call the remote system named by system. This subfield immediately follows the day subfield with no intervening spaces. The times given apply only to days specified by day. If you do not specify a time subfield, your system can call the remote system any time during the given days. The format of this subfield is:

time1–time2

where both time1 and time2 are 24-hour clock times. For example,

WeTh0730-1415

means that your system can call the remote system between 7:30 a.m. and 2:15 p.m. on Wednesdays and Thursdays. This time range can extend over 0000 (midnight), but be careful. It doesn't quite work the way you might expect it to. For example,

Mo2300-0700

does not indicate 11:00 p.m. on Monday through 7:00 a.m. on Tuesday, but rather midnight through 7:00 a.m. on Monday morning and 11:00 p.m. through 11:59 p.m. on Monday evening.

You can specify multiple day/time combinations in an entry by separating them with a comma. For example a Systems file entry containing

Th0800-1600,Fr1215-1900,SaSu

indicates your system can call the remote system during the following times:

• 8:00 a.m. through 4:00 p.m. on Thursday
• 12:15 p.m. through 7:00 p.m. on Friday
• Anytime on Saturday or Sunday

grade

An optional subfield that lets you specify the minimum grade of work file that uucico will send during a given time period (as indicated by the day/time subfields). A grade is a single digit, or a single uppercase or lowercase letter. In order of priority, from highest to lowest, the grades are arranged

0  1  2  …  9  A  B … Z  a  b  …  z

That is, 0 has the highest priority and z has the lowest).

As work files are created for UUCP file transfers, they are automatically assigned grades that determine the order in which they are sent. By default, uux requests have a grade of A and uucp requests have a grade of n.

This optional subfield is separated from a day/time pair by a slash. For example,

MoTu0800-1200/C

indicates that only work files with a grade of C or higher will be sent during the hours of 8:00 a.m. to noon on Mondays.

The grade subfield only controls outgoing files during the given time period. It does not affect incoming files.

retry

An optional subfield that indicates how many minutes after an unsuccessful call to a remote system, uucico should wait before trying to call that system again. This subfield, if specified, appears at the end of the sched field (separated by a semicolon). For example, a sched field of

Any;60

indicates that your system can try to call the remote system at any time and if it is not successful in connecting, it will not try again for 60 minutes.

If you do not include the retry subfield, uucico waits five minutes after the first unsuccessful connection attempt. This waiting period doubles after each subsequent failure.

device_type

Only TCP/IP connections are supported, so specify TCP.

speed

Only TCP/IP connections are supported, so specify – (hyphen).

phone

Only TCP/IP connections are supported, so this field must contain the IP address of the remote system, or a host name by which the IP address is known. You should be able to ping this address. For example, from TSO/E:

ping omvsoe2a
PING V3R1: PINGING HOST OMVSOE2A  (198.151.241.130).  USE
PING: PING #1 RESPONSE TOOK 0.004 SECONDS. SUCCESSES SO FAR

chat_script

A text string that defines the initial login conversation that takes place between your system and the remote system. It has the format:

expect_string send_string expect_string send_string …

where expect_string is the text string that you expect to receive from the remote system and send_string is the text_string that you want to send in response. These two strings are separated by blanks. For example, when you login to a remote system, it responds with

login:

Type

nuucp

and press ENTER. The remote system then replies

password:

Enter your password

Shazam!

and press ENTER.

This conversation can be expressed as the following chat script:

login: nuucp password: Shazam!

This chat script tells uucico to expect the string login. After it is received, reply by sending the string nuucp (automatically sending a newline afterwards). uucico then waits for the string password and replies with Shazam!.

The expect_string can be any part of the string expected from the remote string. Thus, the sample chat script could be written:

ogin: nuucp ssword Shazam!

and yield the same result.

Tip: Omit the first letter of the login and password because some systems might use capital letters for one or both of the words and some might not. To avoid having to find out which way a system is and possible changes on the remote system, the first letters are omitted from the expect string.

The expect_string can be replaced with a string of the format:

expect_string–subsend_string–subexpect_string

where subsend_string and subexpect_string are text strings similar to send_string and expect_string. Hyphens separate the expect_string, the subsend_string, and the subexpect_string. With this format, your system waits for expect_string from the remote system and if it is received within a reasonable length of time, uucico responds with the send_string. If it is not received, uucico sends the subsend_string, waits for the subexpect_string, and then finally sends the send_string.

For example, if you were using a chat script and there was noise on the line that garbled the login: string, the chat script would fail. However, the following chat script might work:

ogin:--login: nuucp ssword: Shazam!

This script waits for login: from the remote system. If it is not received, uucico replies by sending a null string (there is nothing between the two hyphens) followed by a newline. uucico then again waits for login:. When it is received, nuucp is sent. The remainder of the script is identical to the earlier example.

If you want an expect_string to wait a specific length of time for a match, you can suffix the expect_string with a tilde (˜) followed by a number. The number is the number of seconds to wait for the expect_string. For example, the chat script

ogin:˜10--login: nuucp ssword: Shazam!

waits 10 seconds for the string login: before continuing. You can use this suffix with subexpect_string as well.

Table 1 shows the escape sequences which you can use in a chat script.

Table 1. Escape characters that can be used in chat scripts

Escape	Description
""	Expect a null string
EOT	Send the end-of-transmission character
BREAK	Cause a BREAK
\b	Send a BACKSPACE
\c	Suppress newline or carriage return
\d	Delay for one second
\K	Send a BREAK
\n	Send a newline
\N	Send a NULL
\p	Pause for a fraction of a second
\r	Carriage return
\s	Send a space
\t	Send a tab
\\	Send a backslash
\ ˜	Expect a tilde
\ddd	Send the EBCDIC character with octal code ddd. For example, use \100 to represent a space character.