OKP Limitations

What this means is that most user and administrative functions must be carried out using UnixWare 7 interfaces. To mount file systems and devices, for example, you must use the UnixWare mount command, from a Unixware shell prompt, and specify UnixWare-style options, arguments, and device names.

The following sections discuss specific OpenServer facilities that are not provided or supported by OKP, and equivalent UnixWare functionality.

General Limitations

Packaging and Installation

Under OKP, OpenServer custom and custom+ packages can be installed with the limitations listed below:

• When running custom or custom+ inside OKP, a user or system administrator should not elect to "Fix Discrepancies" following software verification. OKP manipulates some of the packaging infrastructure files and attempting to repair them with custom might lead to unexpected system behavior.

• To install from CDROM, it will be necessary to mount the CDROM using the UnixWare mount command, from a Unixware shell, and access its VOL images by explicit path. For example, to mount a CDROM under OpenServer the command is normally something like:

     mount /dev/cd0 /mnt
  

  To mount the CDROM so that it is visible under mnt for OKP processes, enter the following command from a UnixWare shell prompt:

     /sbin/mount /dev/cdrom/cdrom1 /openserver/mnt
  

  See mount(1M).

UnixWare 7 pkgadd format packages can also be installed under OKP.

System administration

UnixWare 7 systems must be administered with the native administrative tools and practices. OpenServer system administration commands are not generally supported, although limited compatibility for some administrative features that are commonly required by applications is included.

OpenServer scoadmin applications must be rewritten to use the UnixWare 7 scoadmin interface and desktop.

Licensing

Some applications either check for or attempt to install an OpenServer license, either as the application is installed or when it is running (or both).

The OpenServer licensing command (brand) and policy manager daemon are not supported on UnixWare. Attempts by OpenServer applications running under OKP to check or install OpenServer licenses will fail.

If an application only applies licensing during installation, the workaround is to install the application on an OpenServer system and then migrate the system and application to OKP. Applications that do runtime licensing checking may need to be rewritten to run under OKP.

The following is a list of utilities and applications known to require runtime licensing that will not run under OKP:

   brand
   calserver
   ifor_pmd
   ifor_sld
   login
   make
   npsd
   pmwm
   sco_cpd
   scologin
   xdt3
   Xsco

In addition, Netscape FastTrack 2.0.1i may experience problems running under OKP. The native UnixWare Apache Web Server should be used instead.

OpenServer Desktop

The OpenServer Desktop (pmwm) does not run under OKP (see ``Licensing'', above). OpenServer desktop applications need to be rewritten to use the UnixWare 7 scoadmin interface and desktop, or can be rewritten to use one of the Linux desktops and run under LKP.

kernel tuneable parameters

Compatibility for OpenServer system tuneables is not provided. If an application requires certain kernel tuneable parameters to be set to certain values, the corresponding UnixWare 7 tuneables must be set using the UnixWare 7 procedures.

Some structures that are sized statically on OpenServer are maintained dynamically on UnixWare 7. In many cases, applications that needed to modify parameters on OpenServer systems will not need to manually tune anything on UnixWare 7.

Note in particular that the maximum reserved size for the stack address space of a process, should not be set to a value greater than 128MB when running OKP. SSTKLIM is the soft limit specifying the maximum size, in bytes, of the stack segment for a process (and is the output of ulimit -s) HSTKLIM is the maximum value of SSTKLIM. The default value for both is 16 MB, which is adequate for most processes. Setting this value higher than 128MB, or to unlimited, may cause an process size error such as the following to be returned when an application is run. For example, setting these values to unlimited and attempting to run netscape returns this error:

   /opt/netscape/netscape: too big

A high value for SSTKLIM/HSTKLIM is also indicated by the following return from the shell builtin pwd command:

   cwdprint

To work around these problems, re-set the value of these parameters to a lower value, or to the default value (0x3FFFFFFF), using the scoadmin system tuner or the idtune(1M) command. The following commands reset the parameters to their default values, rebuild the kernel, and reboot:

   # idtune -c -d HSTKLIM
   # idtune -c -d SSTKLIM
   # idbuild
   # shutdown -i6 -g0 -y

If you need to increase these values to accommodate an application that requires a larger than default stack size, increment the values until the application works correctly, being sure to keep the maximum stack size below 0x7FFFFFFF.

Graphics

Most X.Desktop interfaces call underlying X and Motif functions and so will work on OKP, although a few application pixmaps, bitmaps, and masks from OpenServer may not work.

Networking

UnixWare 7 networking administration is used when running OKP applications. Note that the NetWare UNIX Client Auto-Mounter (NUCAM) is not available on UnixWare 7 so NetWare client applications cannot run under OKP.

readdir() unimplemented for /dev/_tcp

This causes problems for OpenServer binaries that use this call. Most notably, you cannot use the rlogin(1) command to log in to OKP. Programs like tty(1) that use ttyname(3C) will not be able to uncover the actual name of the controlling TTY and will print not a tty.

Mail services

OpenServer mail services will not work under OKP, except for mail delivered to a local mailbox (i.e., on the same system). Mail services should be configured and administered under UnixWare using UnixWare utilities. Use one of the UnixWare mailers (pine, mailx, etc.) to send and receive mail.

Native OpenServer device drivers

UnixWare 7 drivers are provided for most of the standard system peripherals that are supported on OpenServer. See the Certified Hardware listings for information about supported hardware on all platforms.

If you have native OpenServer drivers for specialized hardware required by your application, you will need to rewrite the driver to use the native UnixWare 7 or UDI driver interfaces. Rewriting your drivers to use UDI is the best option; the UDI driver can then be run on OpenServer, OKP, Linux, and other UDI-compliant operating systems and you will not need to maintain multiple versions of the driver. Documentation about writing UDI drivers is included in the UnixWare 7 documentation set available from Documentation web pages.

If you want to port your native OpenServer driver to the native UnixWare 7 interfaces, the "Hardware and Driver Development" topic in the UnixWare 7 documentation set includes information about developing drivers for both OpenServer and UnixWare 7 and includes a large amount of compatibility information to assist you. Specifically, instructions about porting drivers from OpenServer to the native UnixWare 7 DDI driver interfaces, are provided in ``Porting drivers to DDI 8''. Packages of sample drivers and UnixWare 7 test suites can be downloaded from the HDK web page.

Note that the kernel build tools (idtools) are not fully compatible between OpenServer and UnixWare 7. Scripts that install drivers may require some modifications. UDI drivers that run on OpenServer will also run on UnixWare 7 but must be installed following the UnixWare 7 procedures.

Some OpenServer system drivers are not available on UnixWare 7:

• Device compatibility for the /dev/marry, /dev/string, and /dev/table interfaces is not provided.

• The iknt, scancode, and audit OpenServer drivers are not provided.

• The OpenServer power management driver and UPS interfaces are not provided.

• The vidi driver does not set the 9th pixel.

• Access to the OpenServer aio(HW) and vdisk(HW) drivers is not provided on OKP.

• Specific ioctls on OpenServer mass storage devices are not supported.

File Systems

UnixWare 7 file system types are used for OKP. In the migration process, user data files are copied onto native UnixWare 7 filesystems. Note that no direct access to OpenServer HTFS and DTFS filesystem architectures is provided under OKP.

If an OKP application calls a filesystem administration command such as mount, mkfs, or fsck, the native UnixWare 7 version of the command is called rather than the OpenServer version.

System files

The okpfud(1M) daemon synchronizes the contents of OKP versions of key system data files with the contents of the coresponding native UnixWare 7 files, so OKP applications have access to current data. However, the UnixWare 7 version is the master copy, so applications that attempt to modify such data files, either directly or indirectly through OpenServer libraries brought forward to UnixWare 7, are not supported. This affects access to the /etc/passwd, /etc/group, /etc/shadow, /etc/resolv.conf, /etc/utmp, /etc/utmpx, /etc/wtmp, and /etc/wtmpx files.

General exceptions

• No binary compatibility for SCO OpenServer scoadmin applications. These need to be rewritten to use the UnixWare 7 scoadmin interface and desktop.

• No binary compatibility for SCO OpenServer driver binaries. These need to be rewritten to use the UnixWare 7 driver interfaces.

• No binary compatibility for SCO OpenServer desktop applications. These need to be rewritten to use the UnixWare 7 scoadmin interface and desktop.

uname system call

OpenServer processes that make a uname(2) system call will be handed the UnixWare system's utsname information, including a version string of "7.1.3". This probably won't match an OpenServer program's expectations.

OKP works round this by redefining /bin/uname to be a shell script that corrects the values returned by the various uname(1) options to those more normal for OpenServer programs to see. This workround is normally good enough for such things as application installation scripts. However, if an application makes a uname system call directly, it will bypass the /bin/uname wrapper, and may be confused by what uname returns.

In extreme cases, it might be possible to edit the contents of the file /etc/conf/pack.d/name/space.c so that VER is, for example, "5.0.4". This will, however, change the output of uname across the entire system, including for native UnixWare programs. This may lead to unexpected behavior by some UnixWare utilities, and the inability to install or run programs that depend on UnixWare uname values.

SCO OpenServer kernel

• The uname system call always returns information on the UnixWare system version, not the OpenServer version running under OKP. As a result, the OpenServer uptime command always returns:

     Not a 3.2 system
  

• Some undocumented SCO OpenServer flags for the mmap(2) system call functions are not supported.

• The SUDS system call extensions (aio, sem, latch, timers) are not supported. However, most applications try using alternatives if such calls are not available.

• Specific SCO OpenServer system administration or debugging system call support is not provided. For example:

  • cxenix -- syssetconf extra values not supported

  • ptrace -- extra functions not supported

  • waitsys -- extra functions not supported

  • sysi86 -- some features (including PIPE) not supported

  • uadmin -- halt options not supported

• Compatibility for SCO OpenServer system tunables is not provided.

Graphics

• scoterm is unable to run in scancode mode.

• Most application pixmaps, bitmaps, and masks from SCO OpenServer will not work.

• Motif User Interface Language (UIL) files are not portable from SCO OpenServer.

• Applications using IXI Drag and Drop will not work.

• The scoforeground/scobackround X resources from SCO OpenServer are not available.

• Some keyboard definitions provided by SCO OpenServer applications may not work.

Internationalization

If you specify an SCO OpenServer long name as the locale, UnixWare 7 applications will not work properly.

Networking

The file system suffixes used by the NetWare UNIX Client Auto-Mounter (NUCAM) are different from those used on SCO OpenServer. Applications that make assumptions about the format of the file system names mounted automatically by the NUCAM under /.NetWare may fail.

Printing

The SCO OpenServer version of the lpr command is not available. The lpr(1bsd) command on UnixWare 7 is the BSD version. SCO OpenServer-style printer filters cannot be delivered by third parties.

Driver interfaces

• Device compatibility for the /dev/marry, /dev/string, /dev/table interfaces is not provided. The iknt, scancode, and audit SCO OpenServer drivers are not provided.

• The power management driver and UPS interfaces are not provided.

• A small number of console ioctls were not carried forward.

• The mapkey, mapstr, and mapscrn commands are not compatible. See mapkey(1M).

• The vidi driver does not set the 9th pixel.

• The SCO OpenServer AIO and vdisk drivers are not provided.

• Specific ioctls on SCO OpenServer mass storage devices are not provided.

• SCO OpenServer terminfo files are not provided, but can be easily brought forward from /usr/lib/terminfo on SCO OpenServer.

• The kernel build tools (idtools) are not fully compatible between SCO OpenServer and UnixWare 7. Scripts that install drivers may fail.

Filesystems

No direct access to SCO OpenServer filesystems. Data must be archived and/or copied over to the UnixWare 7 system.

System files

Applications that attempt to access SCO OpenServer-specific administrative data files, either directly or indirectly through SCO OpenServer libraries brought forward to UnixWare 7, are not supported.

Applications that attempt to access SCO OpenServer system data files directly or indirectly may experience problem if these files also exist in UnixWare 7 with a different format (for example, utmp).

Security

• SCO OpenServer security calls are not supported. Applications that manipulate user account information, privileges, authorization, and auditing will not work.

• SCO OpenServer security system calls (stopio, getluid, and statpriv) are not supported.

• SecureWare commands are not supported.

• Applications that link with libprot.so may not run with all of the security features expected under native OpenServer.

IPC System Calls and IDs

The system calls shmget(2), msgget(2), and semget(2) return 32-bit IPC IDs under UnixWare. OpenServer and Xenix applications, however, expect IPC IDs that are positive, signed 16-bit numbers. By default, these system calls will continue to return 32-bit IPC IDs.

A new flag, IPC_SMALLID, may be passed in to either shmget, msgget, or semget. If this flag is passed in, then, on success, the invoked function will return a 16-bit IPC ID.

The IPC_SMALLID flag is introduced for use in cases in which a native UnixWare application requires a small IPC ID in order to share the ID and associated object with OpenServer or Xenix applications. The xemul(1) Xenix emulator uses IPC_SMALLID for every IPC ID it requests, so Xenix binaries can use IPC as expected. The kernel has been modified (in Maintenance Pack 2, Update Pack 2, and ptf9001) to always run OpenServer binaries with small IPC IDs.

Three tuneables are also available for cases where the entire system must be tuned to return 16-bit IPC IDs to support an OpenServer or Xenix application running under OKP. These tuneables are SHMSMALLID, MSGSMALLID, and SEMSMALLID. Each has a default value of 0, and a range of values of 0 to 1. Each tuneable controls whether the corresponding IPC system call returns a small id by default. If the tuneable is set to 0, then the corresponding routine returns a 32-bit ID by default; however, if the tuneable is set to 1, then the corresponding routine always returns a 16-bit id.

5.0.4/5.0.5 Manual Pages

The man command does not work under OKP with migrated OpenServer 5.0.4 and 5.0.5 systems. The man command exits with an error like the following:

   man : can't connect to scohttp

To fix this, do the following:

1. Edit the file /unixware/etc/default/okprc and remove the line containing scohttp. Save your changes to the file.

2. Reboot:

      shutdown -i6 -g0 -y
   

3. Enter:

      chmod 777 /openserver//usr/tmp/scohelp.socket
   

5.0.7 Manual Pages

The man command does not work under OKP with migrated OpenServer 5.0.7. The man command exits with an error like the following:

   lynx: Can't access startfile file://localhost/dev/stdin

Switching to a different html to ascii scheme works round the issue. For example, edit /openserver/etc/default/man and change MAN_HTML2ASCII to read as follows:

   MAN_HTML2ASCII=prosaic

This will use prosaic as a man page converter instead of lynx, and allow man to work. Note that prosaic is weaker on HTML table conversion than lynx, so some manual pages may have unreadable tables.

Kernel and Driver Interface Differences

The Unixware 7 kernel differs from the OpenSerever 5 kernel in these respects:

• UNIX95 is supported. Contact your authorized SCO representative for branding information.

• Memory allocation is more dynamic and uses a different set of tunables. This means that the system is more responsive to variations in workloads and there is more flexibility in tuning.

• Modules can be loaded and unloaded dynamically, which results in a smaller kernel footprint.

• There is finer grained locking, and the core kernel is fully multi-threaded. This makes the kernel more scalable.

• A privilege-based mechanism replaces ``superuser'', allowing permissions to be granted on a discrete basis.

• A pre-emptible kernel leads to better real-time performance.

• There are expanded type sizes and UIDs, GIDs, PIDs, dev_ts, and #inodes. This means that there can be more users, processes, devices, files, and so on.

• There is source-level instrumentation for runtime events, including DEBUG assertions, memory leaks, memory corruptions, lock hierarchy checking, and lock statistics. This results in a stronger development process, resulting in superior quality for the non-DEBUG kernels used in the product.

• Pipes, FIFOs, and ttys are based on STREAMS. This means that poll, getmsg/putmsg, module push and similar facilities are available.

• Multi-processor support is limited to the following:

  • Corollary CBUS 2

  • Compaq

Memory management

• SVR4 VM replaces ``regions'' in a completely different implementation. This architecture promotes more page sharing, and provides records of tuneables and performance characteristics, and swap usage.

• File data is now read directly into the page pool, bypassing the buffer cache. Pages may be used by the kernel, freed, and then allocated to a user process.

• There is an auto-tuning facility based on memory size.

• There is a large page size (4MB) for shared memory segments.

• memfs (memory file system) is available for use as high performance temporary files (for example, /tmp and /var/tmp).

  memfs is backed by the swap device, with memory usage dynamically adjusted to match demand. By comparison, a RAM disk device cannot use swap, nor can it vary its memory usage.

Process management

Process management is similar to UnixWare 2 and includes the following:

• Light-weight processes (LWPs) allow parallel execution of multiple threads for the same process.

• There is a user-level threads library.

• Kernel pre-emption is supported.

• Session management represents multiple process groups running over the same tty. That is, job control is available.

• Multiple scheduler classes support real-time, timesharing, and fixed-priority workloads simultaneously.

• There is support for processor binding, integrated with load-balancing mechanisms.

• A /proc filesystem provides access to process state though filesystem namespace (/proc/PID).

• Most commands (such as ps and whodo) are now independent of /dev/kmem.

• debug(1), a powerful tool for debugging user-level programs, is available. Also see ``A guide to debug for dbx users'' in the UnixWare 7 online documentation.

Pseudo-drivers

The following pseudo-drivers are not supported:

• /dev/byte

• /dev/error

• /dev/marry

• /dev/string

• /dev/table

Instead of using the /dev/marry pseudo-driver, swap space can be added dynamically with the swap(1M) command.

Mass storage drivers

Some devices that were supported in SCO OpenServer may not be supported in UnixWare 7. These may include low-end non-SCSI devices such as floppy-tape. Support for such devices may be available from third parties, but this is not guaranteed. Devices that conform to SCSI or IDE/Atapi, with the exception of IDE Tape, should work in UnixWare 7. In addition:

• Device naming conventions are different in UnixWare 7 and compatibility of device node names is not guaranteed.

• Device drivers are not compatible.

• Mass storage ioctls are different in UnixWare 7.

• A different set of mass storage commands is provided.