NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/biz/sco/general/4826

Text File | 1992-12-23 | 18.6 KB | 368 lines

Newsgroups: biz.sco.general
Path: sparky!uunet!uunet.ca!xenitec!news
From: [e-mail] (xenitec.on.ca News Administrator)
Subject: SCO Mailing List Technical FAQ
Resent-From: [e-mail]
Submit-To: [e-mail]
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Thu, 24 Dec 1992 03:01:10 GMT
Message-ID: <[e-mail]>
Precedence: bulk
Lines: 355

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

Revision Information
--------------------
Version:  1.17
Date:     30 November 1992 *** NO CHANGES SINCE LAST POSTING ***
Author:   Stephen M. Dunn
          [e-mail]
          {uunet.ca,becker.gts.org,xrtll.UUCP}!bokonon!stephen
New Features:  Table of contents added; UUCP broken into own section;
               minor editing; added some contact information for
               compressed backup utilities

NOTE:  All lines that have been added or modified since the previous
       version are marked with ** at the start of the line.

****************************NEW SECTION BEGINS*****************************
Table of Contents
-----------------
One Bit of Administrivia

Questions and Answers Common to Unix, Xenix and ODT
-How do I stop banners from printing?
-Are there any screen savers?
-How do I compress my backups?
-My serial connections are losing characters
-I don't like being restricted to 14 character filenames
-How do I get a copy of adb?
-I can't find crypt

Questions and Answers Specific to Unix
-I have a system memory dump in my swap space; how do I delete it?
-How do I save kernel panic dumps to tape?
-At boot time, the "Enter the root password or ^D" message doesn't work!
-My Unix 3.2.0-3.2.2 machine gives errors on filenames greater than 14 chars
-I just upgraded to 3.2v4 but I still can't use long filenames
-The permissions on /usr/adm/sa and its children are wrong

Questions and Answers about TCP/IP and NFS
-telnet doesn't work properly
-How do I know if I have enough streams buffers for TCP/IP and/or NFS?
-TCP/IP gives messages like "Notice: TCP SUM: SRC 89270107  SUM 0000D7AD"

Questions and Answers about UUCP
-I can transfer small files via UUCP but large ones won't go
-I can transfer small files via UUCP but large ones go really slowly
-How do I change uucico's window size?
-I increased my window size but nothing changed
-I increased my window size and UUCP broke!
-UUCP frequently has to resend packets
-How do I chance uucico's packet timeout?
-My data-compressing modem doesn't work much faster than my old modem
*****************************NEW SECTION ENDS******************************

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.  These
two FAQs are posted at the same time at intervals of roughly two weeks.

   Note in particular that if you require instructions on how to
contact SCO, download SLSes, or look at various anonymous archive
sites, you should look in the Administrative FAQ.

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
**(Microlite Corp., 1021 Sutherland Street, Pittsburgh, PA 15204;
**[e-mail] or ...!uunet!mlite!info; [phone] or
**[phone]), BRU (Enhanced Software Technologies Inc.,
**5016 S. Ash Avenue Suite 109, Tempe, AZ 85282; ...!uunet!estinc!info;
**[phone] or [phone]), DBR (DMS Systems Inc., 1111
**Brickyard Road, Salt Lake City, UT 84106; [phone]), or
**Lone-Tar (Lone Star Software Inc., 13987 W. Annapolis Court,
**Mt. Airy, MD 21771; [phone]).  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 the
**operating system.

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.

How do I get a copy of adb?
  If you have the Development System, you already have /bin/adb.  If
  not, you may need to grab a copy from your distribution, or it may
  already have been installed, depending on your OS and version.  It
  could be called /bin/adb (Xenix) or /etc/_fst (Unix and recent
  versions of Xenix).  If you don't have either of these, look through
  the files in /etc/perms for them; in Xenix 2.3.4, you will find one of
  each, which will be in fact the exact same file but on two different
  diskettes.  If the volume on which the file you want is mountable (you
  can check this in the manual, or use the dtype command), then mount it
  and copy the file off.  Otherwise, use tar to extract the file,
  keeping in mind that the filenames on your diskettes are all written
  with relative paths (i.e. ./bin/adb, not /bin/adb).  Note that if you
  look in the Unix documentation, it may well tell you that you need
  /bin/adb, when in fact it's called /etc/_fst.

I can't find crypt
  Most (all?) of SCO's release notes state that due to American government
  restrictions aimed at trying to prevent unfriendly nations from having
  access to data encryption technology, SCO does not ship crypt with their
  products.  If you live in the States and would like crypt(C) and the
  crypt(S) libraries, contact SCO support.  This is also worth trying in
  Canada, as the particular regulation in question permits export of
  such technology to Canada; however, I don't know if SCO will honour
  such requests.

Questions and Answers Specific to Unix
--------------------------------------
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.2v4 will do this for you if you want it to.

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.
  If for some reason you need to convert an EAFS filesystem back to
  AFS, you can use fsck -^P (^P == control-P).  Note that there is
  no performance difference between AFS and EAFS filesystems except
  in accessing long filenames and symbolic links; otherwise, the
  driver code is identical.

The permissions on /usr/adm/sa and its children are wrong
  You have two simple basic choices:
  1.  move the lines from the "sys" crontab file to the "root" crontab file.
    0 * * * 0-6 /usr/lib/sa/sa1
    20,40 8-17 * * 1-5 /usr/lib/sa/sa1
  2.  ensure that /usr/adm/sa is read/writeable by "sys".

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 have been fixed in TCP/IP 1.2; also, the Xenix problem was supposed
**to have been fixed in lng337.

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 :-(
  Under TCP/IP for Unix (and, presumably, the integrated TCP/IP version
  1.2), you can also use the netstat -m command.  Finally, u386mon,
  which is available from many public archive sites, provides
  similar functionality.

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, convert the
  SRC field from hexadecimal (89.27.01.07) to decimal (137.39.1.7).
  There are two common causes for these on high-speed networks, which
  are flaky network cards and slow cards that can't keep up with
  network traffic.  Also, these messages are common on SLIP and PPP
  links.

Questions and Answers about UUCP
--------------------------------
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 or _fst to do this.  See the information on
  getting these which can be found elsewhere in this FAQ.
  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.  If
  you are using Unix 3.2v4, leave the underscore off the symbol name.

I increased my window size but nothing changed
  When UUCP is negotiating a connection, each side will tell the other
  what window size to use when sending.  Therefore, if your window size
  is 7 and the remote uses 3, you will be sending files using a window
  size of 3, but the other side may send with a window size of up to
**7.  Note that the UUCP on the other side may not support the window
**size you specify, and may send with a smaller window than you
**requested.  While this should not cause problems, it may provide
**lower performance than you'd like.

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.
  Some people have reported problems with Telebit modems and UUCP-g
  spoofing when they change their window and/or packet sizes.
  Apparently, Telebits can handle requests for increased window
  sizes without error (though they will only use a maximum window
**size of 3), but will not work correctly with large packets (probably
  above the SCO default of 64 bytes).

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.  If you are running Unix 3.2v4, leave the underscore
  out of the symbol.

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.
[e-mail]              ...!{xrtll,becker.gts.org}!bokonon!stephen
----------------------------------------------------------------------------
Stephen M. Dunn, CNE, ACE, Sr. Systems Analyst, United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7               [phone]