From: news@xenitec.on.ca (xenitec.on.ca News Administrator)
Newsgroups: biz.sco.general
Subject: SCO Mailing List Technical FAQ
Date: 21 Jul 92 07:55:39 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk


          The SCO Mailing List/biz.sco.general Technical FAQ
          --------------------------------------------------

Revision Information
--------------------
Version:  1.12
Date:     08 July 1992
Author:   Stephen M. Dunn
          stephen@bokonon.UUCP
          {uunet.ca,becker.gts.org,xrtll.UUCP}!bokonon!stephen
New Features:  More info on adb, EAFS filesystems

One Bit of Administrivia
------------------------
   There are two different FAQ lists that periodically get posted here.
This is the technical one.  If you have a question regarding net.etiquette
or the administration of these mailing lists/newsgroups, please look for
the administrivia FAQ.  It will probably answer your question.

Questions and Answers Common to Unix, Xenix and ODT
---------------------------------------------------
How do I stop banners from printing?
  You need to edit the file /etc/default/lpd.  You need one of the following
  lines:
  For Xenix:  BANNERS=0
  For  Unix:  BANNERS=nobanner
Are there any screen savers?
  Unix (and Xenix 2.3.4) have a built-in screen saver for VGA only. 
  You have to reconfigure the kernel for this to work.  It doesn't
  work with all hardware, but try it first.  Also, it has been
  reported that VP/ix may not be compatible with this screen saver. 

How do I compress my backups?
  Well, you _could_ just run the output of tar, cpio, or whatever
  through compress ... but if even one bit of your tape or diskette
  goes bad, you'll lose the rest of the backup.  Not recommended at
  all.  A better solution would be a third-party product such as CTAR
  (write to info@microlite.com or ...!uunet!mlite!info), BRU
  ((602) 820-0042), or Lone-Tar ((800) 525-UNIX).  These products tend
  to be fast and robust, and they will usually help you recover from
  disasters far better than the utilities that ship with SCO.  Note
  that CTAR is NOT currently compatible with Unix 3.2.4; a new
  version that will work with 3.2.4 is on its way.  I do not know if
  BRU and Lone-Tar suffer from similar problems.

I have a system memory dump in my swap space; how do I delete it?
  Go into single-user mode (NEVER try this in multi-user mode!).  Then
  copy something into your swap space.  The suggested method is:
	dd if=/etc/termcap of=/dev/swap count=100
  Unix 3.2.4 will do this for you if you want it to.

My serial connections are losing characters
  Here are two possibilities.  First, check the NCLIST kernel parameter.
  This governs how many CLIST structures are allocated; these are used
  to buffer input and output.  If this is too low, then at times of
  high serial I/O demands, your system will run out of CLIST structures
  and start discarding characters.  Note that there is a limit as to how
  many CLIST structures may be allocated to an individual process,
  regardless of how many are available systemwide.  This is done to
  prevent one misbehaving program from monopolizing all of the CLIST
  structures.
  The other possibility is that you may have an old UART (8250 or 16450).
  These chips do not buffer input, and sometimes if a system is busy,
  the occasional character will be lost.  This will show up as an alarm
  in uucico, for example.  The 16550 UART is upward compatible, and it
  has a 16-byte buffer in it.  If you are running Xenix 2.3.4, ODT 1.1,
  or Unix 3.2.2 (or later), the 16550 UART is supported.  This solution
  is not necessarily applicable to multiport serial cards; check with
  the manufacturer of your card.

I don't like being restricted to 14 character filenames.
  If you're running Xenix, or a version of Unix prior to 3.2v4, I'm
  afraid you're stuck.  Unix 3.2v4, however, includes long filename
  support on all EAFS filesystems.  More information on long filenames
  can be found in the section dealing with Unix.

I can transfer small files via UUCP but large files won't go.
I can transfer small files via UUCP but large ones go really slowly.
  This may indicate a flow control problem.  uucico, the program that
  actually performs UUCP transfers, turns off all hardware and software
  flow control on the port it is using.  If your modem's buffers are
  too small, then the stream of data involved in a large file transfer
  may overflow them, causing transmission errors.  This may just cause
  your throughput to go way down, or it may result in a total inability
  to transfer larger files.  Run uucico with debugging (you may find
  /usr/lib/uucp/uutry to be useful) and watch for "alarm" messages.
  If you see these, it's an indication that some characters are
  likely being dropped during transmission.
  If you are using a serial port on a multiport serial card such as
  one from Equinox or Digiboard, your board may have shipped with a
  utility that lets you permanently set flow control on your port.
  Another alternative is to reduce uucico's window size.

How do I change uucico's window size?
  You need to have adb in order to do this.  adb is part of the Development
  System.  If you are running Xenix but do not have the Development
  System, you can find adb on your Xenix distribution.  Look in the
  /etc/perms/dsmd file for ./bin/adb; this file will tell you on which
  distribution disk you can find adb.  If you have Unix, SCO's manual
  will tell you how to use adb to change the window size, but you'll
  actually have to use ./etc/_fst; the same procedure applies for
  extracting it from your distribution.
  First, make a backup copy of /usr/lib/uucp/uucico!  This is very
  important.
  To change the window size to 7, run the following command from the
  Bourne shell:
--------------------8<--------(cut here)--------->8-------------------
adb -w /usr/lib/uucp/uucico << EOF
$d
_windows/w 7
$q
EOF
--------------------8<--------(cut here)--------->8-------------------
  Note that specifying a window size greater than seven will break
  uucico, as the g protocol is designed for a window size of no more
  than this.  Also, the documentation and/or scopatches that ship with
  some SCO products list the second line of the above as "%d".  This,
  at least on the copy of adb I have, will fail; $d is correct.

I increased my window size but nothing changed.
  When UUCP is negotiating a connection, each side will tell the other
  what the maximum window size they support is.  The window size that
  will be used for the connection is the lesser of the two.  Therefore,
  if you increase your window size to 7 but the remote site is still
  using 3, all UUCP connections between your site and the remote will
  continue to use a window size of 3.

I increased my window size and UUCP broke!
  If your modem, or the modem on a remote site, has small data buffers,
  a large window size may cause the modem's buffers to overrun.  If
  the site that broke polls your system, you may wish to create a
  separate copy of uucico with a smaller window size, and specify it
  as the login shell in /etc/passwd.  If you are the polling site,
  you may have to restore your original uucico.  Alternatively, you
  could try a window size of 4, then 5, then 6, then 7, and see at
  what point UUCP stops working.  You will then know the maximum
  window size you can use.  You may also wish to ask the sysadmin
  at the remote site if there is anything they can do, such as
  forcing flow control to be used on their modem, that may remedy
  the problem.  You may, however, have no choice but to return to
  using a window size of 3.

UUCP frequently has to resend packets.
  If you are using a modem with error correction and/or data
  compression, or if you are making a long-distance connection,
  there are delays inherent in your connection which may cause UUCP
  to timeout and resend packets.  You may need to increase the
  packet timeout.

How do I change uucico's packet timeout?
  This is very similar to changing the window size; once again, you
  will need to have a copy of adb, and you must first make a backup
  copy of uucico.  Then run the following Bourne shell command:
--------------------8<--------(cut here)--------->8-------------------
adb -w /usr/lib/uucp/uucico << EOF
$d
_pktime/w 5
$q
EOF
--------------------8<--------(cut here)--------->8-------------------
  Obviously, replace 5 with the desired number of seconds.  Note that
  you should set this parameter to the smallest value that works
  reliably.  If you specify too large a value, it will reduce throughput
  if you encounter a bad line or other conditions that require packets
  to be resent.

My data-compressing modem doesn't work much faster than my old modem.
  There are a couple of possible reasons for this.  Firstly, you may
  be transferring data that has already been compressed and is therefore
  not compressible (compressed news batches, for example).  If your
  modem connects to the remote site using V.42bis data compression,
  this will not adversely affect throughput.  If, however, you are
  using an MNP level 5 connection, you will actually lose
  throughput when sending compressed data.  If the majority of your
  transfers are already compressed, you should disable MNP level 5
  data compression.  Note that using MNP level 3 or 4 error correction,
  or V.42 error correction, without any compression will increase
  throughput regardless of the type of data being transmitted.
  Also, due to the way data compression and error correction in modems
  work, there are delays involved while the two modems agree on whether
  or not each packet of data was received correctly.  If possible, you
  and the remote site should try to increase uucico's window size; this
  will cause more data to be transmitted at once, which will not only
  improve the efficiency of your modem's data compression, but will also
  often mean that the response to a previous packet arrives before the
  window has expired.  I'm afraid a complete discussion of packetization
  and sliding window protocols is beyond the scope of this FAQ; just trust
  me on this one if you don't quite follow me.  Further discussion can
  often be found in the newsgroup comp.mail.uucp.

Questions and Answers Specific to Unix
--------------------------------------
How do I save kernel panic dumps to tape?
  Edit the /etc/dumpsave file.  Yes, I know this answer is incomplete;
  I am working on a better one.

At boot time, the "Enter the root password or ^D" message doesn't work!
  If this message stair-steps across your screen and you can't do a
  ^D, the file /etc/ioctl.syscon has become corrupt.  Go into single-
  user mode by typing the root password followed by ^J instead of a
  carriage return.  Use stty sane^J to restore your console to more
  normal operation.  Remove /etc/ioctl.syscon, and reboot by running
  /etc/reboot.  The system will complain that /etc/ioctl.syscon is
  missing and will rebuild it for you. 

My Unix 3.2.0-3.2.2 machine gives errors on filenames longer than 14 chars.
  There is a tunable kernel parameter, ETRUNC, that controls this
  behaviour.  If set to 1, the kernel will silently truncates filenames
  to 14 characters.  If set to 0, the kernel returns ENAMETOOLONG, in
  accordance with POSIX.

I just upgraded to 3.2v4 but I still can't use long filenames.
  Long filenames only work on EAFS filesystems.  Any new filesystems
  you create will be EAFS filesystems unless you specify otherwise.
  When you upgrade, your root filesystem will automatically be
  converted to an EAFS filesystem, but any other filesystems you have
  will not.
  If you have an existing AFS filesystem that you wish to convert to
  an EAFS filesystem, specify the -E option to fsck; this will convert
  your filesystem into an EAFS filesystem.

Questions and Answers about TCP/IP and NFS
------------------------------------------
telnet doesn't work properly
  There is a known bug in telnetd under Xenix (and probably also under
  Unix), which causes it to be flaky when accessed by certain other
  software (such as Novell's LAN Workplace for DOS).  This is supposed
  to be fixed in the forthcoming TCP/IP 1.2 for both Xenix and Unix;
  also, the Xenix problem is to be fixed in lng337, release date
  unknown. 

How do I know if I have enough streams buffers for TCP/IP and/or NFS?
  Under Xenix, use the program 'sw' (stream watch); it will provide a
  dynamic display of the current and historical usage of various stream
  buffers.  Under Unix, you can use the crash command; the subcommand
  to use is strstat.  There is a version of 'sw' available for Unix,
  but not from SCO.  It can be found on some archive sites; I will
  include more information here when I find where I wrote it down :-(

TCP/IP gives messages like "Notice: TCP SUM: SRC 89270107  SUM 0000D7AD"
  This simply means that TCP detected a checksum error in a packet.  TCP
  is a reliable protocol and will automatically request that the packet
  be re-sent.  This message serves as a notice only and should not be
  of concern unless it occurs frequently.  If you wish to determine
  the IP address of the machine that sent the bad packet, read the
  SRC field backwards (which gives the hexadecimal address 07.01.27.89)
  and convert to decimal (7.1.39.137).  This message usually signals
  either a flaky ethernet card or a slow one that can't keep up with
  the amount of incoming network traffic.
Newsgroups: biz.sco.general