Product Documentation












Late news for SCO OpenServer Release 5.0.6

This document contains information that was obtained too late for inclusion in the documentation shipped with SCO OpenServer(TM) Release 5.0.6 from Caldera. See also the Release Notes and SCO OpenServer Features and Limitations for a complete list of known limitations and workarounds. You should also regularly check the Caldera Support web site for new information on updates, patches, and other support issues.

NOTE: As of May 2001, The Santa Cruz Operation, Inc. (SCO®) Server Software and Professional Services divisions have been acquired by Caldera Systems, Inc. to form Caldera International, Inc. The remaining Tarantella division of the Santa Cruz Operation has changed its corporate name to Tarantella, Inc. The SCO OpenServer product line is now provided by Caldera International, which owns the SCO OpenServer copyrights. For more information, see the Caldera International World Wide Web site:

http://www.sco.com/

Revision history

  • Updated on 8 June 2001 for Release Supplement 506A

  • Updated on 15 December 2000 with 9 new items

  • First published on 1 September 2000

Check back here periodically. New limitations and workarounds will be published as they become available.

Table of contents

Topics described in this document are:

Release Supplement 506A new features

Release Supplement 506A provides new features and bug fixes for SCO OpenServer Release 5.0.6. For more information, see the Release Supplement 506A Release and Installation Notes.

Release Supplement 506A is available on the Supplements CD-ROM in the updated SCO OpenServer media kit. The Supplements CD also includes these new and updated SCO OpenServer supplements:

  • Sendmail Release 8.11.0

  • Uniform Driver Interface (UDI) Runtime Environment Support

  • Universal System Bus (USB) Support

  • Apache Web Server Release 1.3.17
You can obtain these supplements on media from your Caldera distributor or download them from the Caldera website:

http://www.sco.com/support/download.html

The following limitations previously listed on this Late News page have been addressed by Release Supplement 506A:

UUCP does not work
Release Supplement 506A corrects the UUCP problem, and sse037 is no longer neede d.

Incorrect termcap buffer documentation
The termcap(F) manual page has been updated.

Incorrect scoterm environment documentation
The scoterm(XC) manual page has been updated.

ipftest, tcpdump, and etherfind not shipped
The ipf documentation no longer contains references to ipftest, tcpdump, and etherfind, which do not ship with SCO OpenServer systems.

getvar, setvar in tape(C)
The new getvar and setvar options are now documented in the tape(C) manual page.

Netscape Communicator 4.70e Release Notes
Netscape Communicator Release 4.70e has been superceded by Release 4.70f. The current Release Notes for Release 4.70f are correct.
Other limitations listed on this page are still valid.

Changes in /usr/local directory layout

The SCO OpenServer Release 5.0.6 installation creates empty directories (including bin and lib) under /usr/local. This is a change from previous releases that is a potential source of problems, particularly if you have an existing /usr/local hierarchy on a separate filesystem. The /usr/local directories are symlinks in the /opt/K/SCO hierarchy, and during an upgrade, the original /usr/local directories are lost when the symlinks are created. Because the Release 5.0.6 directories are recorded in the custom(ADM) database, any changes made by an administrator after installation will be undone by custom verify operations (using the custom -v or -V options).

If you have added files to the /usr/local directory or its subdirectories, you must back up the directory manually before performing an upgrade. The contents of /usr/local are overwritten during an upgrade installation.

When the upgrade installation is complete, you can copy your files back into the directories within the root filesystem created by the installation. If you want these files elsewhere, create any desired links to other filesystems within the /opt/K/SCO hierarchy, which should make the files visible through the /usr/local directory once again.

Core dump tunables

A new undocumented feature in SCO OpenServer is the ability to control the processes that dump core using tunable parameters in the /etc/conf/pack.d/kernel/space.c file. For more information, see the comments in the file; further documentation will be available in a future release.

WARNING: Use extreme caution when modifying this file. Accidental changes may make your system unusable.

NTP subsystem update

The NTP (Network Time Protocol) subsystem was updated in SCO OpenServer Release 5.0.6 from NTPv3 to NTPv4. As part of this process, the xntpd and xntpdc binaries were removed and replaced with ntpd(ADMN) and ntpdc(ADMN) binaries. Other NTP binaries were also updated to newer versions. NTPv4 is compatible with NTPv3, and the same /etc/ntp.conf file is used, which is identical in most cases.

The ntp_authspeed binary was removed in SCO OpenServer Release 5.0.6.

For more information, see the Time Synchronization Server web site:

http://www.eecis.udel.edu/~ntp/

Applications in scoansi dump core

If you have an existing application that began dumping core with SCO OpenServer Release 5.0.6 and your TERM variable is set to scoansi, try setting $TERM to scoansi -1k and restarting the application. For example,

  • ksh users enter:

    TERM=scoansi -1k; export TERM

  • csh users enter:

    set env TERM scoansi -1k

If this corrects the problem, this means that the application has a termcap buffer that is too small. Contact your application provider to correct the problem; application providers, see the corrected termcap(F) manual page.

Installing with Adaptec 2916x host adapters

If you want to install SCO OpenServer Release 5.0.6 on a device connected to an Adaptec 2916x SCSI host adapter or compatible devices, you must use the ad160 driver from the CD boot image or from the SCSI host adapter Boot Time Loadable Driver (BTLD) disk. The ad160 driver is not included on the primary installation disk, and you will receive "Host adapter not found" error messages if you try to boot from this disk.

If you boot from the installation CD-ROM, the driver will be available for the installation process. If you boot from floppy disks, you must first install the ad160 driver from the SCSI host adapter BTLD disk as described in ``Installing boot-time loadable drivers'' in the SCO OpenServer Handbook. For more information, see ``Boot devices and media'' in the Release Notes.

Installing on Adaptec dual channel host adapters

If you want to install SCO OpenServer Release 5.0.6 on a device connected to an Adaptec 3916x Dual Channel SCSI host adapter or dual Adaptec 2916x SCSI adapters, your CD-ROM and hard drives should be on the primary bus of the first configured adapter. If the devices are attached to different channels or devices, the order of controllers may be changed after reboot and the devices may not be recognized. This is a known bug that will be addressed in a future driver release from Adaptec.

Non-primary hard disk divisions not available

Some divisions configured during installation on a second SCSI hard disk might not be available after installation and are displayed by divvy(ADM) as not named.

To make those divisions available, use divvy after installation to name the divisions, but do not make any other changes with divvy. Then, install the updated division table to make all divisions available as configured.

Video adapter might require accelerated video driver

Most video adapters can be operated with the generic VESA video driver. A more limited range of video adapters can be operated with accelerated, hardware-specific drivers. When a hardware-specific driver exists, the SCOadmin Video Configuration Manager will identify it. Accelerated drivers usually perform much faster than the VESA driver.

If you experience problems with the operation of a video adapter, try switching between its accelerated and VESA drivers. An adapter not behaving correctly with one driver might operate correctly with the other. Specifically, if you experience system hangs with the Number Nine SR9 AGP video adapter using the VESA driver, you should configure and use the accelerated video driver to avoid this problem.

Remove SCODB before upgrading

If SCODB, the kernel debugger, is linked into the kernel prior to an in-place upgrade, the upgrade fails with an error message similar to: 

   undefined symbol - scodbinit
To avoid this problem, before trying to upgrade to SCO OpenServer, deactivate SCODB in the link kit by changing Y to N in the file /etc/conf/sdevice.d/scodb.

If the system has already been upgraded, you can correct the problem by editing the file /etc/conf/cf.d/mdevice. but be careful not to damage the format of this file because you cannot reconstruct it without reinstalling the system. On the line for ``scodb'', change the second field from ``P'' to ``PI''. (Because of the risk involved in editing /etc/conf/cf.d/mdevice, it is safer to deactivate SCODB, as described above, before upgrading.)

Upgrading to the Enterprise configuration from Host or Desktop

During an upgrade installation of a SCO OpenServer Release 5.0.6 Host or Desktop System to Release 5.0.6 Enterprise System, you are prompted to enter your Enterprise license. Supply the license information from your Release 5.0.6 Enterprise System Certificate of License and Authenticity (COLA); do not choose to install the 60-day evaluation license because there is no built-in evaluation license for SCO OpenServer.

If you select the 60-day evaluation license, after installation the Enterprise system is in an unlicensed state, the License Manager shows the Host or Desktop license, and the Software Manager shows the Host or Desktop software as installed. To clear these unnecessary entries from the License Manager and Software Manager and to ensure that your system is licensed correctly, performing the following steps after installation:

  1. Remove the Host or Desktop license from the License Manager.

  2. Remove the product database for the Host or Desktop software:

    rm -r /opt/P/SCO/product

    Replace product, with unixos for the Host software or with odtps for the Desktop software.

  3. Change directory to /etc/conf/pack.d/kernel.

  4. Run the brand(ADM) command using the Enterprise license from your Release 5.0.6 COLA to make sure all the appropriate files are updated on the system.

    If your COLA has a license data string, enter:

    brand -g -a "license_data" license_number license_code os.a

    For example:

    brand -g -a "k1;q1;m9zyxwv" NUM123ENT xexfmyub os.a

    If your COLA does not have a license data string, enter:

    brand -g license_number license_code os.a

Then, relink the kernel and reboot the system.

For more information, see ``Upgrading to the Enterprise configuration from Host or Desktop'' in the SCO OpenServer Handbook.

/etc/default/lang errors

On a system installed in French or German, after reboot, you will see a series of errors similar to this: 

   iserrno = 117

This error can be ignored and should not cause any problems.

Configuration and startup changes for TCP/IP

Under certain conditions, it might appear that the network on your SCO OpenServer Release 5.0.6 system is not functioning properly. Upon closer inspection, you might discover that a default route has not been set or that a routing daemon did not start as expected. This might be due to changes in how configuration information is stored and changes in the TCP/IP startup script.

You might encounter these problems if you:

  • performed a fresh installation of SCO OpenServer Release 5.0.6 and deferred networking configuration

  • performed an upgrade installation where the original system contained modifications to the network configuration

  • used netconfig(ADM) to set up your network, but could not find where to enter the desired configuration parameters

To get your network functioning properly:

  1. Determine the current network configuration on your system.

  2. Understand how the installation has changed and where these network configuration parameters are stored.

  3. Understand how TCP/IP startup behavior has changed.

  4. Restart the network or the system (if necessary) to fix the problems you have encountered due to these changes.

Determining the network status of your system

You can check if a default route exists by displaying the routing tables with:

netstat -r

This command produces output similar to: 

  Routing tables
  Destination      Gateway            Flags    Refs      Use  Interface
  default          gateway1           UGS        38   355378  net0
  localhost        localhost          UH         37    52026  lo0
  198.0.0          system1            UC          1        0  net0
  system1          localhost          UGHS        2       30  lo0
  BASE-ADDRESS.MCA system1            UGS         0        0  net0
(If you have trouble with name resolution, you can display network addresses instead of system and network names by adding the -n option to the netstat(TC) command.)

If the destination column does not contain an entry for ``default'', then a default route has not been configured on your system.

You can check if a router daemon is running by entering:

ps -e | egrep "gated|routed"

If the command returns with no output, no router daemon is running, which is normal for many network configurations because it is usually sufficient to have a default route that redirects outbound network traffic to a specific network interface. A router daemon is only needed on certain complex network configurations. If a router daemon is needed, your network administrator should be able to identify the correct daemon for your network. In no case should more than one routing daemon be running.

To see if the resolver configuration file has been set up as you expect, take a quick look at it with:

cat /etc/resolv.conf

If the file does not exist or does not have the values you expect, you can edit this file manually -- see resolv.conf(SFF).

New network parameters during initial installation

The network configuration screen of the initial installation has some new fields for TCP/IP configuration, which affects how network configuration files are created and used.

Gateway address
You can configure a default route by supplying the IP address of the system to which network traffic should be directed if no other routes can resolve the destination. The value you place in this field is stored in the file /etc/default/tcp as the GATEWAY variable, which is used by the /etc/tcp startup script to determine if a default route should be established. If the variable is set, the startup script executes the following command:

route add default $GATEWAY $DFLT_METRIC

If you leave this field blank during initial installation, the ``GATEWAY='' line in /etc/default/tcp exists without a value assigned. Because the variable is not set, /etc/tcp does not establish a default route.

NOTE: DFLT_METRIC is also in /etc/default/tcp to specify a default metric for the route command, but is not set. You can edit the /etc/default/tcp file to place the desired value on the ``DFLT_METRIC='' line.

Nameserver addresses
You can configure a primary DNS nameserver and a secondary DNS nameserver by supplying the IP addresses, which are then stored in /etc/resolv.conf. If you leave both of these fields blank during initial installation, the file /etc/resolv.conf is not created.

NOTE: To supply a third nameserver address, you should edit the /etc/resolv.conf file manually after installation.

Startup behavioral changes

Two routing daemons (routed and gated) are available, but they are mutually exclusive. One (but not both) of these daemons can be configured to start by editing the configuration file /etc/default/tcp. The variables ROUTER_DAEMON and ROUTER_DAEMON_ARGS in that file should contain the absolute path to the daemon to be used and the arguments with which to start that daemon, respectively.

These variables are not set during installation, so routing daemons will not be started automatically for you. This is fine if you have specified a gateway address, or do not require routing tables, but if your system participates in a larger network where routing tables are updated through the routing daemon propagation protocols, you must specify which daemon to use and its arguments by editing the /etc/default/tcp file and filling in the fields. For example: 

   ROUTER_DAEMON=/etc/routed
   ROUTER_DAEMON_ARGS=-q
or 
   ROUTER_DAEMON=/etc/gated
   ROUTER_DAEMON_ARGS="-f /etc/gated.conf"

These variables might not exist in the /etc/default/tcp file if you have performed an upgrade from a pre-5.0.6 system. If automatic start up of one of these daemons is required, simply add the appropriate definitions to the /etc/default/tcp file.

Be sure to unset the GATEWAY variable, if its existence is inappropriate with the running of one of these daemons.

Read the manual pages for routed(ADMN), gated(ADMN), and gated.conf(SFF) for further information on setting up these daemons.

Restart procedures

A change made to /etc/resolv.conf is used by new processes requiring name resolution services. Some daemons, or long-running programs, might need to be restarted to reread /etc/resolv.conf. If you detect inconsistent name resolution behavior, you might need to either restart the services that are not working properly or reboot the system.

Changes to /etc/default/tcp require a restart of TCP/IP using one of these methods:

  • In most situations, you can restart the TCP/IP network by simply running these commands:

    /etc/tcp stop
    /etc/tcp start

    The new network environment should reflect the changes you made.

    or

  • In some situations, you might need to reboot the system (for example, if network does not start up properly or if some service that requires network connectivity became confused when the network was restarted).

Changes to the contents of /etc/resolv.conf

In this release of SCO OpenServer, the /etc/resolv.conf file might be created for you during a fresh installation; however, if you examine this file, you might notice that the domain line is missing, which is intentional because the domain line is redundant with the search line. While the domain keyword is still legal, if the domain line appears after the search line, the search line is ignored. To prevent confusion or misunderstanding, the /etc/resolv.conf file is now created without the domain line.

Other configuration information placed in the /etc/resolv.conf file during installation includes:

  • primary nameserver

  • secondary nameserver

  • hostresorder (local first, BIND second)
The /etc/resolv.conf file is created only if nameserver addresses and the system domain name were entered during initial installation.

For more detailed instructions on resolver configuration, see the resolv.conf(SFF) manual page.

Restarting the calendar server with IQM_LANGUAGE

The steps given in ``Calendars'' in the SCO OpenServer Handbook to restart the calendar server with the initial LANG setting are not correct.

Below are the correct steps:

  1. Change directory to /usr/lib/sco/oadb and remove all the data files in the caldata directory with:

    cd /usr/lib/sco/oadb
    rm caldata/*

  2. Enter:

    DBKEY=6373
    IQMFILE=/usr/adm/ISL/iqm_file
    . $IQMFILE
    LANG=$IQM_LANGUAGE
    export DBKEY IQMFILE LANG

  3. Change directory to /usr/lib/scosh/utilbin and rebuild the database with:

    cd /usr/lib/scosh/utilbin
    ./calbuild

You should now be able to administer the calendar database.

To make this change permanent on your system, you must also:

  1. Edit the file /etc/rc2.d/P95calserver and find the line: 
    DBKEY=6373;     export DBKEY

  2. Before that line, add: 
    IQMFILE=/usr/adm/ISL/iqm_file
. $IQMFILE
LANG=$IQM_LANGUAGE
export IQMFILE LANG
This will enable the calendar server to start using the locale that was set at installation time, regardless of the system locale setting.

DOS session requires ansi terminal type

If you start a DOS session from a tty running the ``scoansi'' terminal type, DOS does not work correctly. If you exit the DOS environment and set the terminal type to ``ansi'', then DOS works correctly.

Access to the Apache web server manual pages

To provide system-wide access to the Apache web server manual pages, modify /etc/default/man as follows: 

   MANPATH=scohelp:/usr/man:/usr/local/man:/usr/local/lib/apache/man
That is, add /usr/local/lib/apache/man to your MANPATH.

After setting up your MANPATH, follow the instructions in the Apache Release Notes on the SCO Skunkware CD-ROM.

Complete documentation on the Apache web server is available in the Apache manual. After installing the Apache web server , the Apache manual can be accessed via the URL:

file:/usr/local/lib/apache/htdocs/manual/index.html


DOCUMENTATION
SCOoffice
UnixWare 7
OpenServer
Knowledge Center