Systems man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

Systems(4)							    Systems(4)

NAME
       Systems	-  Contains  information about remote systems that can be con‐
       tacted using the uucp program.

SYNOPSIS
       /usr/lib/uucp/Systems

DESCRIPTION
       The /usr/lib/uucp/Systems file contains an entry for each remote system
       that the local system can communicate with using uucp. The uucp program
       cannot establish a connection with a remote system  unless  it  has  an
       entry  in  the  Systems	file.  The Systems files must be configured on
       each system running the uucp program.

       Note that only someone with root user authority can  edit  the  Systems
       file, which is owned by the uucp login ID.

   Fields in the Systems File
       The  Systems  file should contain a description of each system that the
       local system can establish a remote connection with.  Each line in  the
       Systems file includes the following fields:

       sys_name Time Caller Class Phone Login

       The  name  of the remote system.	 In general, names should be a maximum
       of seven characters in length and must be unique.  To  insure  compati‐
       bility  with  some  older  systems, names should only include lowercase
       characters and digits.

	      There can be more than one entry for each sys_name.  Each	 addi‐
	      tional entry for a specific system represents an additional com‐
	      munications path that uucp will sequentially try	if  communica‐
	      tion  cannot  be	established using an earlier entry.  Specifies
	      the times when the local system  can  call  the  remote  system.
	      This  field consists of three subfields: day, for the day of the
	      week (required), time, for the time of the day when  the	system
	      can  call (optional), and retry, for the minimum retry period in
	      minutes (optional).  The day and time subfields  are  not	 sepa‐
	      rated with spaces.  The retry field is separated by a semicolon.

	      The day subfield is specified using the following keywords: sys‐
	      tem can call on any day system can never call the remote system.
	      The remote system will have to call the local system.  any week‐
	      day.  You can also use Mo, Tu, We, Th, Fr, and Sa,  for  example
	      MoWeFr, for Monday, Wednesday, and Friday.

	      The day subfield is required, unlike the time and retry fields.

	      The  time	 subfield  is specified contains two times, in 24-hour
	      clock notation, which specify a range of times.  Leave this sub‐
	      field  blank if the remote system can be called at any time dur‐
	      ing the day.  For example, if a remote system can only be called
	      during the morning, enter 0800-1200 in the subfield.

	      The time subfield can also specify when the remote system cannot
	      be reached if the time range entered spans 0000.	 For  example,
	      0800-0600	 means the remote system can be contacted at any time,
	      except between 6:00 am and 8:00 am.

	      Multiple time fields can be included by using a comma as a sepa‐
	      rator.   For  example, WK1800-0600,Sa,Su means the remote system
	      can be contacted at any time on a week day except	 between  6:00
	      pm. and 6:00 am, and at any time on Saturday and Sunday.

	      The optional retry subfield, specifies the minimum time, in min‐
	      utes, before uucp can try again to contact a remote system after
	      an  unsuccessful	attempt.  This	subfield is separated from the
	      rest of the string by a semicolon.  For example,	Any0800-1200;3
	      specifies	 that  3  minutes  is  the  minimum period after which
	      uucico can try this  system  again  once	it  has	 been  invoked
	      explicitly  or by the cron daemon. Usually, uucp will attempt to
	      contact the remote system twice and if uucp fails, it will exit.
	      The uucp command can be invoked again after the 3 minute period.
	      Specifies the type of connection to be used to communicate  with
	      the  remote system.  Use the ACU keyword for a telephone connec‐
	      tion using a modem or  TCP  (for	a  connection  using  TCP/IP).
	      Alternatively, sys_name can be used for a hardwired connection.

	      If TCP is used, there is a subfield which specifies a conversion
	      protocol.	 The default is the g protocol.	 Other	protocols  are
	      e,  f, and t which are faster and more efficient than the g pro‐
	      tocol.  To specify a particular protocol, place a comma and  the
	      protocol letter after TCP, for example TCP,f.

	      The  entry  specified  in	 this  field must have a corresponding
	      entry in the /usr/lib/uucp/Devices file.	The speed in bits  per
	      second for the device.  Unless it is necessary to use a specific
	      baud rate, use the keyword Any. This instructs uucp to  match  a
	      speed that is appropriate for the ACU of system connection spec‐
	      ified in the Caller field.

	      For a telephone connection, the rate you	enter  in  this	 field
	      should  correspond  to a rate specified in the Class field of an
	      entry in the /usr/lib/uucp/Devices file.

	      For a TCP connection, do not specify a baud rate.	 Instead,  use
	      a	 hyphen,  -, as a placeholder.	The phone number used to reach
	      the remote system.  For a hardwired or  TCP  connection,	use  a
	      hyphen, -, as a placeholder.

	      The  phone number can be the complete phone number of the remote
	      system or a combination of an alphabetic abbreviation that  rep‐
	      resents  the dialing prefix and the remainder of the number; see
	      Dialcodes(4).

	      An equal sign, =, in the phone number indicates  a  wait	for  a
	      secondary dial tone.  This may be required when a special number
	      sequence must be used to access an outside  line,	 for  example.
	      For  modems  that	 do not have the ability to detect a secondary
	      dial tone, the = sign generates a pause instead.	A  hyphen,  -,
	      in  the  phone  number  generates	 a  1-second pause.  The “chat
	      string” which describes the initial conversation between systems
	      to  complete  the	 login	procedure.   The  string  consists  of
	      “expect-send” pairs (separated by spaces) and  optional  “subex‐
	      pect-subsend” pairs (separated by hyphens).

	      The  “expect”  portion contains characters that the local system
	      expects to receive from the remote system.  The  “send”  portion
	      contains a string of characters that are sent to the remote sys‐
	      tem upon receipt of the “expect” string.	For example, the first
	      expect  string  generally	 contains  the	remote	system's login
	      prompt, and the first send string generally contains  the	 login
	      ID  to  be  used on the remote system.  The second expect string
	      contains the remote password prompt and the second  send	string
	      contains the remote system's password.  For example,

	      in: uucp word: sysuucp

	      Note  that  the expect portion in the example contained only the
	      trailing part of the full strings	 expected,  login:  and	 pass‐
	      word:,  respectively.   The  expect string only needs to contain
	      part of what is expected.	 This helps  to	 avoid	problems  with
	      remote  systems  that  may  use  Login:  or Password: instead of
	      login: and password:.

	      The use of “subexpect-subsend” strings is shown below:

	      in:--in: uucp word: sysuucp

	      In the example, the local system expects to receive  the	string
	      in:.   If the local system gets that string, uucp goes on to the
	      next field in the “expect-send” sequence, which  is  uucp.  How‐
	      ever, if the local system does not get that string, it sends its
	      own string, which	 is  enclosed  by  hyphens  after  the	expect
	      string.	In  the	 above example, a null character followed by a
	      newline is sent.	The local system then  expects	the  in:  (the
	      second  instance of it in the example).  The newline sent to the
	      remote generally causes it to respond with its login prompt, and
	      the login ID can be sent followed by password processing.

	      The  following  strings can be included in the Login field: Null
	      character Backspace Suppress the newline at the end of the  send
	      string  Delay two seconds before sending or reading more charac‐
	      ters Pause for approximately .25 to .50 seconds Turn on the echo
	      check  (useful  in Dialers file) Turn off the echo check (useful
	      in Dialers file) Send a BREAK character Newline Carriage	return
	      Space  character Tab backslash character EOT character.  Two EOT
	      newline characters are sent BREAK character (same	 as  \K)  Col‐
	      lapse  the  octal	 digits	 (ddd)	into a single character before
	      sending.

	      The following example is shown below as two lines due to screen-
	      width  limitations.   As	a typical example entry in Systems, it
	      would actually be one line:

	      host1 Any ACU 1200 ch6412 "" login:--login: uucp word: sysuucp

	      In this example, host1 can be called at any time (Any)  using  a
	      phone  connection	 (ACU)	at  1200 baud.	The phone number is ch
	      (which is defined in the Dialcodes file) followed by 6412.  Ini‐
	      tially,  the  local system expects nothing (indicated by "") and
	      sends a sequence of four carriage returns with two-second delays
	      separating  them	(\r\d\r\d\r\d\r). This is typical for a remote
	      system that must	read  characters  before  presenting  a	 login
	      prompt.  Finally, the login is executed, using login ID uucp and
	      password sysuucp.

FILES
       Contains information about available devices Contains dial-code	abbre‐
       viations Contains information about modems used for uucp communications
       links

SEE ALSO
       Daemons: uucico(8)

       Commands: ct(1), cu(1), uutry(1), uucp(1), uucpsetup(8)

								    Systems(4)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net