1    New and Changed Features in Version 4.0

This chapter provides brief descriptions of features that were new to the DIGITAL UNIX system in this release or had changed significantly from previous releases.

1.1    Common Desktop Environment

The Common Desktop Environment (CDE) is the new default graphical user interface for DIGITAL UNIX. The CDE environment is designed to provide common services across all UNIX platforms, including a consistent user interface for end users and a consistent development environment for application developers across multiple platforms.

CDE on DIGITAL UNIX is based on the X Window System Release 6 (X11R6) and CDE/Motif 1.0 (OSF/Motif 1.2.4), and supplies the following desktop services and applications:

CDE is provided in seven software subsets that require a total of 57.81 MB of free disk space for installation. See the Installation Guide for information on the subset names, contents, and sizes.

The CDE kit contains the following migration tools:

1.1.1    CDE Video Tour

A brief multimedia tutorial of CDE is located on the DIGITAL UNIX V4.0 Associated Products Volume 1 CD-ROM. Once installed, the video tour can be accessed via the application manager in the "Information" folder. The user simply needs to double click the "CDE Video Tour" icon.

1.1.2    CDE Screen Savers

The CDE session manager supports X11R6 screen saver extensions and you can now select animated screen savers instead of a blank screen. This release also enables the automatic locking of screens after a specified idle time. Both features can be modified or disabled from the CDE Style Manager menu. Click on the Screen icon, and select the options you want.

1.2    X/Open-Compliant Curses

This release provides a new Curses implementation that incorporates the following sets of programming interfaces:

1.3    X11R6

This release of DIGITAL UNIX supports Release 6 of the X Window System, Version 11 (X11R6) patchlevel 12. Prior versions of the operating system supported Release 5 (X11R5) patchlevel 26.

The DIGITAL UNIX port of X11R6 supports all the features and functionality of previous releases of DIGITAL UNIX. It also supports all X Consortium standard features of X11R6.

Included in new features are the following protocol extensions:

1.3.1    X Keyboard Extension for X11R6 (XKB)

The XKB (X Keyboard) server extension is new for X11R6 and for DIGITAL UNIX Version . XKB enhances control and customization of the keyboard under the X Window System by providing the following:

In addition, the X11R5 AccessX server extension for users with physical impairments has been incorporated into the XKB server extension. X11R5 applied to versions of DIGITAL UNIX that preceded this release. These accessibility features include StickyKeys, SlowKeys, BounceKeys, MouseKeys, and ToggleKeys, and control over the autorepeat delay and rate.

Several applications that make use of XKB features are also new with DIGITAL UNIX version 4.0. These applications include Xdec, xkbcomp, xkbprint, xkbdfltmap, dxkbledpanel, dxkeyboard, and accessx. Refer to the reference pages for more information.

Note that the final revision of the X Keyboard Extension, XKB Version 1.0, will be different from XKB Version 0.65, which is shipping with this release. Avoid creating code that directly references the XKB API and data structures. Any X clients created with direct references must be recompiled and relinked when XKB Version 1.0 is shipped in a future release. You may also have to modify your source code.

1.4    DXImageview

DXImageview version 1.0 is an OSF/Motif application for viewing a variety of image file types such as GIF and JPEG. DXImageview supports the Common Desktop Environment (CDE) recommended integration for applications. DXImageview is provided in the subset OSFCDEAPPS400 and is installed as /usr/bin/X11/dximageview. The -help option displays information on using the application.

1.5    Commands and Utilities

The following new or changed commands and utilities are available in this release.

1.5.1    Changes to Mtools

Mtools software is included in the OSFDOCTOOLS400 subset. In prior releases, the software was installed by an optional worldwide support subset.

1.5.2    sendmail Utility Supports Configurable GECOS Fuzzy Matching

The sendmail utility now allows the user to configure the fuzzy logic for mail delivery. Previously, if the recipient's address did not precisely match any of the user names on the host, a best-match algorithm was applied against the GECOS field in the passwd file. If a unique best-match was found, the mail was delivered to this user. This behavior is now run-time configurable using the -oG option on the command-line. See sendmail.cf(4) for more information.

1.5.3    df Supports Large File Systems

The field width for the Iused and Ifree fields in the output of the df command has been increased to accommodate 12 digits when using the -i switch. This modification was made to support very large file systems where the number of inodes could exceed the field width that was previously set aside for these fields.

1.5.4    Compressed Reference Pages

To economize on disk space, reference pages are now shipped in compressed format. Compressed files were created with the /usr/bin/gzip utility. The man and xman utilities automatically uncompress the reference pages.

If required, you can uncompress reference page files manually with the /usr/bin/gunzip utility.

The catman command has also been enhanced to work with compressed catman files. All three commands, man, xman and catman, still provide support for uncompressed manpages. The CDE online help viewer also automatically uncompresses reference pages when they are accessed via a hyperlink in a help volume.

For more information, refer to the man(5) and the catman(8) reference pages.

1.5.5    Enhancements to terminfo

Terminal support has been enhanced to support non-DIGITAL terminals. Entries have been added to the terminfo databases and the termcap file to enable this support. New tools have also been added to assist users in modifying or porting other termcap and terminfo entries to DIGITAL UNIX. These include the following:

The tput and tic utilities have also been enhanced.

1.5.6    GNU Emacs Version 19.28

GNU Emacs has been updated to Version 19.28. This version is not upwardly compatible with GNU Emacs Version 18.5, the previous version shipped with DIGITAL UNIX. Refer to the appropriate GNU emacs documentation in /usr/lib/emacs/etc.

1.5.7    Netscape Navigator

This release contains Version 1.12I of the Netscape Navigator World Wide Web browsing program. Invoke the Netscape Navigator from a CDE desktop icon, located in the CDE Application Manager's Desktop_Apps group. The Netscape Navigator can be invoked directly from the command line by running /usr/bin/X11/netscape. You can access detailed help on the Netscape Navigator through the help menus.

A DIGITAL UNIX home page can be found in /usr/doc/netscape in the the file named Digital_UNIX.html. The home page contains links to helpful documentation, including a local copy of the Netscape Navigator User's Handbook (consider adding this link to your list of Netscape bookmarks).

The DIGITAL UNIX Installation Guide contains information on how to set up Netscape. See Chapter 6, which covers postinstallation setup tasks.

1.5.8    dxterm

The dxterm terminal utility has the following new features:

See the dxterm(1X) reference page for more information.

1.5.9    Performance Manager

Performance Manager is a real-time performance monitor that allows users to detect and correct performance problems. Graphs and charts can show hundreds of different system values, including CPU performance, memory usage, disk transfers, file-system capacity, and network efficiency. Thresholds can be set to alert you to correct a problem when it occurs, commands can be run on multiple nodes from the graphical user interface, and archives of data can be kept for high-speed playback or long-term trend analysis.

1.5.10    utilupdate

A new utility, utilupdate, updates the setld, and optionally ris and dmu utilities on servers that are running a Version of DIGITAL UNIX prior to Version 4.0. It is necessary to run this utility on the server prior to attempting to serve DIGITAL UNIX Version 4.0 clients.

The setld, ris, and dmu utilities have been modified for Version 4.0 to allow them to work with the new format of the distribution media. For more information on the use of this utility, refer to the Sharing Software on a Local Area Network manual.

1.5.11    Bootable Tape

This release introduces the ability to create a standalone bootable tape of the operating system. You can boot from the bootable tape as easily as you can boot from CD-ROM or a RIS area, but without the overhead of selecting or installing subsets. When you restore your system from the bootable tape, you must reconfigure your system using the System Management applications. You will need to adjust system parameters, such as the host name or IP address,

The binaries and shell scripts needed to create and restore a bootable tape are installed with the base operating system. The files reside in OSFBINCOM400 and no other subsets are needed. OSFBINCOM400 is the Kernel Header and Common Files (Kernel Build Environment) subset. The files used by the bootable tape utility include:

You use the btcreate utility to create a standalone bootable tape. To extract and restore file systems from tape at the single-user level, you use the btextract utility.

For more information, see the btcreate(8) and btextract(8) reference pages.

1.5.12    Partition Overlap Checks Added to Disk Utilities

Partition overlap checks have been enhanced or added to the following commands:

newfs ufs_fsck mount

The checks ensure that partitions will not be overwritten if they are marked in use in the fstype field on the disk label. The overlap checks also ensure that no overlapping partition is marked in use.

If a partition or an overlapping partition has an in-use fstype field in the disk label, the following commands inquire interactively if a partition can be overwritten or not:

newfs mkfdmn addvol
swapon voldisk voldisksetup

Refer to the reference pages for more information.

Partition overlap checks have been generalized by creating two library functions: check_usage and set_usage. Two new fstype values have been added: FS_RAW and FS_DB. For example, the library function set_usage could be used by database applications to set the fstype field of a disk partition that is in use by the database. Similarly, check_usage can be used to determine the usage of a disk partition or any overlapping partition.

1.5.13    scsimgr Utility for Creating Device Special Files

The scsimgr utility creates device special files for newly attached disk and tape devices. This utility is automatically invoked at system boot time. You can execute the command to add device special files for all disk and tape devices attached to a specified SCSI bus at any time. See the scsimgr(8) reference page for further details.

1.6    SysMan System Management Applications

This release includes a new suite of graphical single system management applications called SysMan. These applications support installation, configuration, daily administration, and monitoring and tuning. Some of the SysMan applications require you to have superuser privileges or offer a restricted interface to non-privileged users.

At installation time, you can use the graphical Installation Setup application to select software and configure disks.

The graphical applications are integrated into the Common Desktop Environment (CDE). The SysMan applications are available from the CDE front panel by clicking on the Application Manager icon and double clicking on the System_Admin group icon.

There are five groups of system management utilities:

The following sections list the system management utilities.

1.6.1    Installation

This release provides full installations for new systems, and update installations to update systems from DIGITAL UNIX Version 3.2C, Version 3.2D-1, or Version 3.2D-2 to DIGITAL UNIX 4.0.

1.6.1.1    New Installation User Interfaces

Two new user interfaces are available for the DIGITAL UNIX full installation process:

The type of interface presented during the full installation is determined automatically based on your hardware. Systems with graphical consoles and 32MB or greater main memory will provide a graphical interface to the installation. Systems with consoles that do not have graphics capabilities or have insufficient memory to support graphical installations provide a text-based interface.

1.6.1.2    New Format of Distribution Media

As in previous releases, there are two types of media to install the DIGITAL UNIX operating system onto your system:

However, for Version 4.0, the CD-ROM contains file systems that are laid out just as the software would be installed on the system and contains directly accessible root, /usr, and /var areas. This format makes every operating system command and utility available to the installation process. This means that UNIX commands required for recovery procedures such as restoring corrupt file systems are readily available even if your operating system is not yet fully functional. The new format also eliminates the need for the environment previously known as the Standalone Environment, which was a primitive, limited operating system environment.

1.6.1.3    Installation Name Changes

In DIGITAL UNIX Version 4.0, you can perform a default or custom full installation. In previous releases, these installation types were called basic and advanced, respectively.

The installation procedure still provides access to a UNIX shell that lets you recover from serious system problems such as root file system corruption or to perform general file system or disk maintenance tasks before or during the installation. In previous releases, this option was called the System Management option. In Version 4.0, it is known as the UNIX Shell.

1.6.1.4    Enhancements to the Installation Procedure

The following enhancements have been made to the installation procedure:

1.6.1.5    Cloned Installations

The ability to perform a cloned installation is available in this release. A cloned installation enables you to duplicate the file system layout, file system type, and software subset selections from a similar system that has already been installed with DIGITAL UNIX Version 4.0. Installation cloning can only be performed using RIS. If your system is registered to a RIS environment and has a configuration description file (CDF), the installation procedure retrieves the CDF and uses the system configuration information stored in the CDF to configure and install your system.

1.6.2    Configuration Applications

After a full installation, the SysMan Configuration Checklist will be displayed and can be used to configure your system. The order in which the applications are presented is a logical order in which to configure your system. You can skip any applications that are not needed for the current configuration.

The following graphical applications are also available in the Configuration group under System_Admin in the Application Manager group once the installation is complete:

In addition, the CDE Application Manager has a launchpoint for NIS Setup, which is a command-line interface for setting up Network Information Services (NIS), such as centralized password and user group files.

Each of the graphical configuration applications has a corresponding setup script that can be used through a character-based interface.

1.6.2.1    Bind Configuration

The bind configuration utility, bindconfig, provides streamlined management of BIND and DNS (Domain Name Services) services on a host. Bind configuration supports the creation and management of name service clients and servers and provides the complete range of configurations permitted by BIND.

Use this application to:

1.6.2.2    Disk Configuration

The disk configuration utility, diskconfig, manages certain disk operations for the base system.

Use this application to:

1.6.2.3    Mail Configuration

The mail configuration utility, mailconfig, configures the sendmail utility.

Use this application to:

1.6.2.4    Network Configuration

The network configuration utility, netconfig, manages network hardware and related services on a host. This application supports the configuration and management of networking adapters on a host, and provides maintenance of network services and related data files.

Use this application to:

1.6.2.5    NFS Configuration

The NFS configuration utility nfsconfig, manages the Network File System (NFS) and related processes on a host.

Use this application to:

1.6.2.6    Print Configuration

The print configuration utility, printconfig, manages the printcap file, print daemon specific directories, and files.

Use this application to:

1.6.2.7    Internationalization Configuration

Internationalization configuration is available if the optional worldwide support subsets are installed. See Section 1.13 for more information.

1.6.3    Daily Administration Applications

There are eight applications for the daily administration of your system:

1.6.3.1    Account Manager

The account manager utility, dxaccounts, is used to manage user accounts. It operates on both base security level systems and enhanced security (C2) level systems. You must have root privileges to modify account databases.

Use NIS to centrally manage user accounts in a network environment. NIS allows participating systems to share a common set of passwd and group files.

The account manager allows you manage both the local and NIS account databases. NIS uses a client-server model. To make changes to the NIS databases, you must run the account manager on the machine designated as the NIS server.

The account manager offers views of each of the system databases. By default, the account manager starts by displaying the Local User view showing the contents of the /etc/passwd file. The supported views are:

Please refer to the account manager online help for more information.

1.6.3.2    Archiver

The archiver utility, dxarchiver, provides graphical access to the tar, cpio, pax, and compress commands.

Use this application to:

Archiver functions are classified as follows:

1.6.3.3    File Sharing

The file sharing utility, dxfileshare, allows the importing and exporting of NFS file systems. You can run it with or without superuser permissions. If you are not root, access to system files is restricted so that you can only view, but not modify, locally exported file systems and perform mounts to user directories.

Use this application to:

1.6.3.4    Host Manager

The host manager utility, dxhosts, manages X clients. You can use this application to change X host permissions for hosts and to execute X applications remotely on a host. Other applications in this tool suite use it as a host name resource.

Use this application to:

1.6.3.5    License Manager

The license manager utility, dxlicenses, provides access to DIGITAL's License Management Facility (LMF).

This application allows you to:

1.6.3.6    Shutdown Manager

The shutdown manager utility, dxshutdown, shuts down and optionally reboots your system.

The following options are available:

When the main window expands, the following options are also available:

1.6.3.7    System Information

The system information utility dxsysinfo, displays and monitors system resources on a DIGITAL UNIX system.

Use this application to:

1.6.3.8    Audit Manager

The Audit Manager, dxaudit, allows you to create audit reports. For more information see the Security manual and the dxaudit(8) reference page.

1.6.4    Monitoring and Tuning Applications

The applications described in this section help you to monitor and tune your system.

1.6.4.1    Kernel Tuner

The kernel tuner utility, dxkerneltuner, manages attributes of loadable kernel subsystems.

Use the kernel tuner to:

1.6.5    Storage Management

The CDE Application Manager provides launchpoints for Storage Management applications in the System Admin group.

The applications that are available depend on what software you have installed. A launchpoint for the Logical Storage Manager is available with the base operating system.

1.6.6    Tools

The CDE Application Manager provides launchpoints for Tools in the System Admin group.

The System Management suite includes four launchpoints in this area. Each runs an output-only command in a window that permits you to repeat the command on demand or at intervals.

The launchpoints and their commands are:

If you want to run another output-only command, you can run one of the commands in this group, then change the current command in the user interface.

1.7    Standards

This release complies with many new and changes standards. Refer to the standards(5) reference page for more information.

1.7.1    Realtime Is Compliant with Final POSIX 1003.1b Standard Interfaces

As of this release, DIGITAL UNIX completes the implementation of the POSIX 1003.1b standard interface as approved by the IEEE standards board in September 1993 (IEEE Std 1003.1b-1993, Realtime Extension). See the Guide to Realtime Programming for more information. The new features are described in sections Section 1.8.11, Section 1.8.12, and Section 1.8.13.

1.7.2    DECthreads Is Compliant with Final POSIX 1003.1c Standard Interfaces

As of this release, the DECthreads library libpthread.so implements the POSIX 1003.1c standard interface as approved by the IEEE standards board in June 1995 (IEEE Std 1003.1c-1995, POSIX System Application Program Interface). The new POSIX (pthread) interface supported with DECthreads is the most portable, efficient, and powerful programming interface for a multithreaded environment. These interfaces are defined by pthread.h. See the Guide to DECthreads for more information.

1.7.3    DEC C Compiler Complies with ISO C 94

In this release the DEC C compiler and libc implement the ISO C 94 standard. This behaviour is obtained by calling the DEC C compiler with the -isoc94 flag. This feature is not available with the -oldc compiler option, which invokes the previous compiler.

1.8    Development Environment

This release includes the following enhancements to the development environment.

1.8.1    Tcl/Tk Availability

Tcl/Tk is now available as part of the base operating system. Tcl/Tk is a public domain unencumbered scripting language and graphical tool kit. In addition to Tcl/Tk, a popular extension package, TclX is also included. TclX provides many UNIX extensions to the Tcl command language. Tcl version 7.4, Tk version 4.0, and TclX version 7.4 are included in this release. See the Installation Guide for information on how to identify and install the appropriate software subsets.

The available programs are:

1.8.2    DEC C++

The following changes have beem implemented for DEC C++.

1.8.3    Replacement of the pixie Utility

The previous version of the pixie utility has been relocated to the file /usr/opt/obsolete/usr/bin/pixie and is provided as part of the OSFOBSOLETE subset. The previous version of pixie will be retired in a future release and is replaced with the Atom-based pixie utility. A driver for the Atom-based pixie is located in /usr/bin/pixie, for backward compatibility with the previous version. The driver accepts the same switches recognized by the previous version. Refer to the pixie(1) and atom(1) reference pages for more information on pixie and general information on the Atom tools.

1.8.4    Software Development Environment Repackaging

The Software Development Environment (SDE) has been repackaged to ease installation, simplify licensing, and create a product identity. The current SDE components have been repackaged into a single, new OSFSDE subset and all of the pieces outside the SDE have been moved into logical subsets, including:

Because the compiler is needed at installation time, some SDE components have remained in the mandatory OSFCMPLRS subset.

The Ladebug debugger subsets have been renamed to the OSF* subset name prefix and can now be installed during a custom installation of DIGITAL UNIX. These changes have been made on the DIGITAL UNIX Operating System Volume 1 CD-ROM. The FUSE Porting Assistant has been added to the DIGITAL UNIX kit on the DIGITAL UNIX Associated Products Volume 1 CD-ROM. This is a tool to help port code to DIGITAL UNIX from a variety of platforms and operating systems.

The OSFSDECDE subset was also added to the DIGITAL UNIX Operating System Volume 1 CD-ROM. It contains the files necessary to access DECladebug and the Porting Assistant from CDE.

1.8.5    DEC C Compiler

The C compilers, cc and c89 on DIGITAL UNIX have changed to DIGITAL's DEC C compiler. The previous default C compiler is still a supported viable option and can be accessed by specifying -oldc on the cc and c89 command lines.

DEC C uses DIGITAL's back-end compiler (GEM) technology, which has been specifically developed and optimized for use with Alpha systems. Both compilers have full binary compatibility with each other.

1.8.6    Init Execution Order Modified for Static Executable Files

The execution order for init routines in static executable files has been modified to more closely match the execution order for init routines in dynamic executable files. The init routines loaded from an archive library will be executed prior to any init routines loaded from objects and archives occurring earlier on the linker command line. Prior to this change, init routines were executed in the order they were encountered in processing the link command from left to right. As a result, init order for static executable files was much different than the init order for equivalent shared executable files.

For existing applications that rely on the static inito rder used in prior releases of DIGITAL UNIX, the new linker option: -old_init_order can be used to restore the strict left-to-right execution order for static executable files.

1.8.7    PC-Sample Mode of prof Command

The prof command's pc-sampling mode now supports profiling the shared libraries used by a program. Linking a call-shared program with the cc command's -p switch causes the resulting program to profile both the call-shared executable file and all the shared libraries. The following command displays a combined profile:

#  prof -all

New -all, -incobj, -excobj, and -stride switches for the PROFFLAGS environment variable enable you to request per-procedure profiling of the shared libraries or to select particular libraries to profile.

Related enhancements are:

See the prof(1) and monitor(3) reference pages for further information.

1.8.8    atom and prof Commands and Threads

The following atom and prof commands now profile the shared libraries used by a program:

#  atom -tool pixie -all

and

#  prof -pixie -all

Also, the threads environment for theatommakes pixie tool thread-safe, though per-thread counts are not recorded.

See the atom (1), prof (1), and pixie (5) reference pages for further information.

1.8.9    Thread Independent Services (TIS) Interface

DIGITAL UNIX Version introduces the Thread Independent Services (TIS) application programming interface in the C run-time library libc. TIS provides services that assist in the development of thread-safe libraries.

Thread synchronization may involve significant run-time cost, which is undesirable in the absence of threads. TIS enables thread-safe libraries to be built that are both efficient in the non threaded environment, yet provide the necessary synchronization in the threaded environment.

When DECthreads (pthreads) are not active within the process, TIS executes only the minimum steps necessary. Code running in a non threaded environment does not encounter overhead incurred by the run-time synchronization that is necessary when the same code is run in a threaded environment. When DECthreads are active, the TIS functions provide the necessary thread-safe synchronization.

1.8.10    High-Resolution Clock

DIGITAL UNIX Version has an optional high-resolution clock. To enable this option, add the following line to the kernel configuration file and rebuild the kernel:

options MICRO_TIME

The system clock ( CLOCK_REALTIME) resolution as returned by clock_getres will not change. Timer resolution remains the same. However, time as returned by the clock_gettime routine will now be extrapolated between the clock ticks. The granularity of the time returned will now be in microseconds. The time values returned are SMP safe, monotonically increasing, and have 1 microsecond as the apparent resolution.

1.8.11    POSIX 1003.1b Realtime Signals

Realtime signals have been implemented to conform to the POSIX 1003.1b standard. This new feature includes queued signals with optional data delivery, and 16 user-definable realtime signals.

The following functions to support realtime signals were implemented:

1.8.12    POSIX 1003.1b Synchronized I/O

Synchronized I/O (file synchronization) has been implemented to conform to the POSIX 1003.1b standard. New functions for synchronized I/O under the UFS and ADVFS file systems include:

The open function now takes the following new flags for synchronized I/O:

1.8.13    POSIX 1003.1b _POSIX_C_SOURCE Symbol

For applications conforming to POSIX 1003.1b, the _POSIX_4SOURCE macro is supported for this release, but will be retired with the next release of DIGITAL UNIX. The macro _POSIX_4SOURCE is part of an obsolete draft standard and is supported in this release for compatibility only. When possible, existing applications which use _POSIX_4SOURCE should be modified to use _POSIX_C_SOURCE instead.

The _POSIX_C_SOURCE macro is associated with a value, which allows an application to specify the namespace it requires. However, as a general rule, avoid explicitly defining standards macros when compiling your applications. For most applications, the header file unistd.h provides the standards definitions needed.

1.8.14    Digital Porting Assistant

The Digital Porting Assistant is a Motif-based tool to help you port your C, C++, and FORTRAN source code to DIGITAL UNIX from other UNIX and proprietary platforms, including OpenVMS. The Porting Assistant provides the following features:

The Porting Assistant is licensed and provided to you with DIGITAL UNIX Developers' Toolkit but requires separate installation.

To install Version 2.0 of the Porting Assistant, install subsets PRTBASE200 and PRTMAN200 (and their dependencies) from the DIGITAL UNIX Associated Products Volume 1 CD-ROM..

1.9    Networking

The following networking enhancements have been implemented.

1.9.1    New Version of the gated Daemon

This release includes a new version of the gated routing daemon. The update installation procedure will detect if your system is configured to run the gated routing daemon. If the DIGITAL-supplied gated is detected then the /etc/gated.conf file is moved to /etc/ogated.conf. Otherwise, if a user supplied or customized gated is detected, then both the /etc/gated.conf and the /usr/sbin/gated are saved with the .PreUPD suffix.

When the system is installed, the new gated R3.5 is the default version in /usr/sbin/gated. The old gated version 1.9 is supplied in /usr/sbin/ogated. Also, corresponding older gated reference pages are saved with an o prefix.

1.9.2    Dynamic Host Configuration Protocol (DHCP)

This release contains both a client and a server Dynamic Host Configuration Protocol (DHCP) daemon. For DHCP client configuration, use the netconfig utility. For configuration of client parameters on the DHCP server, use the /usr/bin/X11/xjoin utility, which provides a graphical user interface to the /etc/bootptab file.

For more information on DHCP, refer to the joinc(8) and joind(8) reference pages.

1.9.3    Point-to-Point Protocol (PPP)

This release supports Point-to-Point Protocol PPP, including support for BSD-style compression of entire packets. This is a negotiated option. If a foreign peer cannot handle this, it should be gracefully rejected via the Protocol-Reject of LCP.

When using PPP with modems doing compression, it may be desirable to force no BSD-style compression. To do this, put -bsdcomp in either /etc/ppp/options, or on the pppd command line.

PPP now has a configurable (at boot time) number of interfaces. The default is 1. To specify a higher value, add the following line to the /etc/sysconfigtab file and reboot the system:

ppp: nppp=x

PPP documentation is available in the pppd(8), pppstats(8), and chat(8), reference pages and in the Network Administration Guide.

1.9.4    NFS over TCP

This release contains DIGITAL's first implementation of NFS support over the TCP transport. Previously, only the UDP transport was available. UDP is still available and may still be the preferred transport in local area networks. For NFS access over wide area, congested, or lossy networks, TCP may offer better performance.

Use the nfssetup script or the nfsconfig utility to enable TCP on the NFS server.

The nfsiod daemon has been changed to spawn kernel threads (instead of forking multiple processes as it did previously). Each nfsiod thread can handle UDP or TCP mounts, so the command nfsiod still accepts one argument.

1.9.5    Extensible SNMP

A new SNMP architecture is present in this release. The SNMP daemon, snmpd, is now an extensible master agent. End user programmers can develop subagent programs that communicate with snmpd to implement their MIBs on DIGITAL UNIX systems.

The base operating system MIB support is implemented in a subagent program called os_mibs, which is started/stopped automatically with snmpd.

1.9.6    SNMP MIB support

This release supports the Host Resources MIB (RFC 1514). The MIB support daemon must query the system's devices to retrieve information required for this MIB. This query occurs when the daemon starts, and subsequently whenever a relevant SNMP request arrives.

This device querying is the default behavior, and may be configured off. See the snmpd(8) reference page for more information about configuring the SNMP agent.

1.9.7    telnet and mrouted

The following new features were implemented:

1.9.8    Network Time Protocol (NTP)

The xntp utility has been upgraded to Version 3.0, which is a complete implementation as defined in RFC 1305.

Note that the new ntpdate utility requires that the version of the server be specified with the -o flag. For example:

%  ntpdate -o 2 server.oxo.fff.com

The default version is 3.

The new xntpd daemon supports authentication. If you choose to enable this option, note that you only have to provide keys to the servers and peers that also support authentication.

You should provide names of three servers during setup with ntpsetup, choosing the mode server and the version option V2 (In the case where you are not upgrading the servers).

1.10    Enhanced Security

This release provides the following new enhanced security features.

See the Security manual and the setrlimit(2), edauth(8), and convuser(8) reference pages.

1.11    File Systems

The following file system enhancements have been implemented in this release.

1.11.1    AdvFS

The following new features were introduced for AdvFS.

1.11.1.1    New Tuning Parameters for AdvFS

There is a new mechanism for limiting the amount of kernel memory that AdvFS uses for its access structures. This may be necessary only for systems with 64 Mb or less memory, and AdvFS as the default file systems. This is applicable to all hardware configurations.

There are two new kernel paramaters relevant to AdvFS that can be modified using the sysconfig or sysconfigdb commands. They are AdvfsAccessMaxPercent and AdvfsAccessCleanupPercent. There is a complete description of these parameters in the Guide to File System Administration for the POLYCENTER Advanced File System and Utilities for DIGITAL UNIX.

1.11.1.2    AdvFS Now Supports Directory Truncation

Traditionally, AdvFS directories were never truncated, even though many of the files in the directory had been deleted. This created a problem if the directory file became very big. For example, if several hundred thousand files were added to a directory, then the directory file itself grew very large. Even though most of the files in that directory were subsequently deleted, operations that required scanning the directory remained inefficient because the entire directory file still needed to be read.

AdvFS now truncates directory files when all of the entries at the end of the directory have been deleted. This truncation is done on 8KB byte boundaries, so the size of a directory is always a multiple of 8192.

One ambiguity of directory truncation is that the truncation is done when files are created and not when they are deleted. This is done because of the efficiency of underlying algorithms, and is the same model used by UFS for directory truncation. For example, after most files in a given directory are deleted, the size of the directory file itself will not decrease until a new file is inserted into that directory.

1.11.2    File System Access Control Lists (ACLs)

ACLs (Access Control Lists) on files and directories are a new feature in this release. They are manipulated with the getacl and setacl commands. See the Security manual and the reference pages for more information.

1.11.3    Logical Storage Manager

DIGITAL UNIX Version provides the following new features for the Logical Storage Manager (LSM):

The functionality and syntax of the LSM commands used for encapsulation, unencapsulation, and mirroring have changed in this release, as follows:

1.11.4    Overlap Partition Checking

Two new functions, check_usage and set_usage3 are available for use by applications. These functions check whether a disk partition is marked for use and set the fstype of the partition in the disk label. See the reference pages for these functions for more information.

1.12    Bootstrap Linking and Kernel Modules

In DIGITAL UNIX , a new method for configuring and building kernels is in place. It is designed to meet future needs for modularity, configurability, maintainability, scalability, and third-party device installation. Although the internal details of building kernels has changed significantly, the external interface is almost identical. The System Administration guide and Writing Device Drivers: Tutorial guide contain more detailed information on this process. For normal operations, a static vmunix is recommended. Bootstrap linking is intended to support foreign devices, where support for such devices is not delivered in DIGITAL UNIX.

Previously, the DIGITAL UNIX kernel was comprised of over 1000 individual .o files. The configuration procedure, doconfig, selected among those files, and compiled a static kernel image that was then installed and booted. The .o files are still available in the base kit and can be loaded separately if required.

In this release, the .o files are grouped into 150-200 modules, with the suffix .mod. Each module represents a functional piece of the kernel, such as a device driver or platform support module. These modules are the new form of the original dynamically loadable modules introduced in DEC OSF/1 Version 3.0.

Modules are selected by doconfig instead of the individual files previously used. This simplifies the Makefiles, saves considerable disk space, and reduces compilation time.

1.12.1    Defining Modules

There is a new syntax in the files file for making modules:

Module Definition Syntax
MODULE/[STATIC]/modname optional opt1 ....
dir/file1.c module modname
dir/file2.c module modname
dir/file3.c module modname

This procedure defines a module: modname.mod (note that .mod is appended to modname automatically). Each module has three files: file1.c, file2.c, and file3.c. When each file has been compiled, the module is linked together, and is ready to build into a kernel.

Optionally, STATIC may be specified before the module name. If it is omitted, the object files are merely linked together into a module. If STATIC is used, the module is assumed to have a modname_configure() routine and modname_attributes[] table to make it a configurable and potentially loadable module. Linkages to these routines are made in the kernel's static_subsys_list[] table, and the configure routines will be called at system startup. See System Administration for more information on modules, making modules loadable, and the use of configure routines.

If an individual file in BINARY is rebuilt, the module that contains it must also be rebuilt to incorporate the change into the kernel. To help with this, an environment variable DO_MODULES is checked. Providing that the value of DO_MODULES is the string AUTO, a module will be automatically relinked whenever an individual file is rebuilt. Kernel developers are encouraged to put their files into modules, and to consider making them loadable if possible.

1.12.2    Bootstrap Linking

To enhance configurability, and help mainstream modules, a new technology called bootstrap linking has been created. This is a way to defer the actual linking of a kernel until boot time. It is provided as an alternative to booting a statically linked kernel.

When you run doconfig it builds a static kernel by default. To build a bootlink kernel, the command option -b must be explicitly specified.

A bootstrap linked kernel is actually a set of directives in a sysconfigtab file that tell the bootstrap program how to build the kernel in memory. This file is generated using the make sctab rule, which will be invoked by doconfig.

The updated file is placed into /usr/sys/MACHINE/sysconfigtab. It must be copied into the root file system, and the two machine-specific modules MACHINE.mod and EXTRAS.mod copied into the /sys/BINARY directory. The sysconfigtab file is then given to the bootstrap program instead of vmunix to build and boot the new kernel.

See also the doconfig (8) and sizer (8) Reference pages for more information.

There is one major restriction when using a bootstrap linked kernel. Because there is no vmunix executable file, programs that attempt to search the kernel's symbol table will not find one. This includes dbx and nm, and most of the compiler tools. Programs that use the nlist library call and pass the name of the booted file will work, even if that file is a sysconfigtab file. To avoid this restriction in DIGITAL UNIX , execute:

#  ld -o <filename> `sizer -m`

This will generate an exact copy of the currently running kernel complete with symbol table in the file <filename>.

When building a bootstrap linkable kernel, doconfig first builds a static kernel. If the static kernel fails to build, do not attempt to bootstrap link the sysconfigtab file. Note that this static kernel will not be identical to the bootstrap-linked kernel as the kernels may be linked at different addresses. Use the ld command if required.

1.12.3    Related Changes

To effect full kernel modularization, several internal changes were made to the config program and the compile environment for kernel files. These changes are significant for anyone developing kernel drivers or layered products.

See the doconfig(8) and sizer(8) reference pages for more information.

1.13    Internationalization and Language Support

The following new features have been implemented to support internationalization.

1.13.1    Internationalization (I18N) Configuration Utility for CDE

The I18N Configuration Tool, available through the CDE Application Manager, is one of the SysMan system administration configuration tools. The I18N Configuration Tool provides a graphical interface that enables you to configure internationalization-specific settings. It also provides a convenient way to see which countries, locales, fonts, and keymaps are currently supported on your system. Use this tool to remove unused fonts and unrequired country support.

1.13.2    Unicode Support

This release provides a new set of locales and codeset convertors that support the Unicode and ISO 10646 standards. The codeset convertor modules enable an application to convert between other supported codesets and UCS-4.

DIGITAL UNIX also provides a function called fold_string_w() that maps one Unicode string to another, performing the specified Unicode character transformations. For more information on the fold_string_w() function, see the fold_string_w(3) reference page.

For more information on the Unicode support, see the Unicode(5) reference page.

1.13.3    The Worldwide Mail Handler No Longer Exists

Worldwide support subsets no longer install internationalized Mail Handler (MH) software in the /usr/I18N/bin/mh directory. In DIGITAL UNIX Version 4.0, internationalization features have been merged into the default Mail Handler (MH) whose files are located in /usr/bin/mh. Check the value for the mhpath resource used to find the DECwindows Mail application. If necessary, change this value to be /usr/bin/mh.

1.13.4    Multilingual Emacs (mule)

The mule editor is a multilingual version of GNU Emacs and supports the following kinds of characters:

The IOSWWMULE400 subset installs Version 2.3 of the GNU mule editor and associated software. Corresponding sources are available in the IOSWWMULESRC400 subset.

DIGITAL UNIX does not include public domain fonts that you can use with mule. Refer to the mule-2.3/README.Mule file installed by the IOSWWMULESRC400 subset to find out how you can obtain public domain fonts.

The DIGITAL UNIX software is enhanced with lisp libraries that support the dechanzi codeset for Simplified Chinese and the dechanyu codeset and tsangchi input method for Traditional Chinese. These libraries are included in the IOSWWMULE400 subset and installed in the /usr/i18n/mule/lib/mule/site-lisp directory.

For more information about mule, see the mule(1) reference page.

1.13.5    Support for Catalan, Lithuanian, and Slovene

DIGITAL UNIX Version 4.0 includes support for the the Catalan(5), Lithuanian(5), and Slovene(5) reference pages for information about associated codesets, locales, keyboards, and fonts.

1.13.6    man Command Supports Codeset Conversion

The man command can automatically invoke the iconv utility to perform codeset conversion of reference page files. This allows you to install one set of reference pages to support locales that have the same language and territory but different codesets, thereby reducing file redundancy on the system. For more information, refer to the man(1) reference page.

1.14    PCMCIA (PC Card) Support

PCMCIA (PC Card) support is a new feature in this release and is limited to the following capabilities:

1.14.1    Restrictions

The following restrictions apply in this release.

However, other ISA to PCMCIA bridge adapters using the Intel i82365SL or compatible chip may also work.

1.14.2    Configuring the PCMCIA Adapter Board from the Console

Before inserting the PCMCIA adapter board into your system, make sure to read the manual that came with the adapter from the adapter vendor and follow the instructions on how to connect the cables and install the board.

1.14.3    Configuring and Using a PCMCIA Modem PC Card

Since a PC Card is a dynamic device (i.e. not a static device that is present all the time in the system hardware), and the serial-line device driver is a static device driver, when the system is installed initially, there will not be a corresponding acex entry created automatically by the doconfig of the target system. This is due to the fact that the system doesn't know when it is being installed that there will be a fax/modem card for PCMCIA since the card is not in the system yet.

If you want the system to automatically create the 'acex' entry for your PCMCIA fax/modem card, before you start installing the system, make sure that you have the PCMCIA adapter configured in the console and that the PCMCIA fax/modem card is inserted into the slot. If you have a fax/modem card in the slot 0, for instance, when the system is installed and the target kernel is built, the system kernel configuration file built will have the following entry: 

controller ace2   at pcmcia0  slot 0 vector aceintr

The installation will also create the device special file for this fax/modem card in the directory named /dev.

#  ls -gl tty02 

crw-rw-rw-   1 root     system    35,  2 Oct 16 13:22 tty02

If you didn't have the PCMCIA fax/modem card inserted in the slot when the system was installed, then you need to add the following line to your system kernel configuration file, /sys/conf/HOSTNAME where HOSTNAME is the name of your system. If you are just going to use one PCMCIA fax/modem card: 

controller              ace2    at *    slot ? vector aceintr

If you plan to use 2 modem cards simultaneously, add the following 2 lines to your system configuration file: 

controller              ace2    at *    slot ? vector aceintr
controller              ace3    at *    slot ? vector aceintr

Once the system configuration file is modified, use the following command to rebuild the new kernel and reboot the system.

#  doconfig -c

1.14.4    Creating a Device Special File for the Modem Card

Normally the system installation will create the following two default tty0x device special files in the directory /dev, as the following command shows:

#  ls -gl tty0*

This command produces output similar to the following: 

crw-rw-rw-   1 root     system    35,  0 Oct 16 13:22 tty00
crw-rw-rw-   1 root     system    35,  1 Oct 16 13:22 tty01

This is because most systems have 2 imbedded serial lines. If the system has only one, only tty00 entry will be visible in the /dev directory.

Create additional device special files for the PCMCIA modem cards using the MAKEDEV utility in the /dev directory.

For example, in the /devdirectory:

#  ./MAKEDEV ace2 

MAKEDEV: special file(s) for ace2:
tty02

The generated special file should look like this: 

crw-rw-rw-   1 root     system    35,  2 Oct 27 14:02 tty02

If you intend to have 2 PCMCIA modem cards working simultaneously, create device special files for the number of cards, in this case, 2. For example, in /dev directory:

#  ./MAKEDEV ace2 ace3 

MAKEDEV: special file(s) for ace2:
tty02
MAKEDEV: special file(s) for ace3:
tty03

The generated special file should look like this: 

crw-rw-rw-   1 root     system    35,  2 Oct 27 14:02 tty02
crw-rw-rw-   1 root     system    35,  3 Oct 27 14:02 tty03

1.14.5    /etc/remote File

The /etc/remote file must be modified to add new access line definitions for the PCMCIA modem cards to be used. If you have a 28.8kpb modem card and will be using the full speed, the baud rate (br) in the /etc/remote file should be set to 38400.

For example, add the following line to /etc/remote file: 

line2:dv=/dev/tty02:br#38400:pa=none:

Note that in the above line, "line2" can be any name you determine to be used with the "tip" command later on.

Once the PCMCIA modem card is inserted correctly and the system configures the card, the card can be used the same as any other modem devices.

1.14.6    Inserting a PCMCIA Modem Card

To use a PCMCIA modem card, insert the card to one of the PC Card slots in the PCMCIA adapter. Depending on the adapter type, there may be 2 front access card slots or one front access and one rear access card slot. When you insert the card into the slot 0, you should see the following message on the console terminal (or the Console Log window of the graphics head). 

# PCMCIA socket 0: card manufacturer: MEGAHERTZ
product name: XJ2288
Configured: serial unit 2, type=16550A
ace2 at pcmcia0

This example used MegaHertz XJ2288 fax/modem card.

1.14.6.1    Possible Error Message

When a modem card is inserted, an error message such as the following example may appear on the Console Log window: 

socket 0: card manufacturer: MEGAHERTZ, unknown modem card inserted

 

Using generic modem driver for this PC Card.

 

PCMCIA socket 0: card manufacturer: MEGAHERTZ

 

product name: XJ1144

 

socket 0: Couldn't find usable config. for this card.
Please eject this PC Card.

The error message: 

Couldn't find usable config. for this card.

is generated if the card requires I/O resources that are already in use by other components in the system. If this error message is seen, the card should be ejected since it is not configured.

One possible way to correct this situation is to remove some other ISA/EISA devices in the system and reboot the system, thus freeing I/O resources that may be required by this card and trying the card insertion again.

1.14.7    Removing a PCMCIA Modem Card

Once you are finished using the modem card, push the button next to the card slot to eject the card previously inserted. You should see the following message on the console terminal or console Log window. 

# stray interrupt on unit=2, intr_id=0
PCMCIA socket 0: PC Card removed

Note that you may or may not see the "stray interrupt..." message above when you eject the card. The message is generated by the serial-line driver if the PC Card generated an interrupt when the card got ejected.

1.15    Dynamic Device Recognition for SCSI Devices

Dynamic Device Recognition (DDR) is a framework for describing the operating parameters and characteristics of SCSI devices to the SCSI CAM I/O subsystem. You can use DDR to include new and changed SCSI devices into your environment without having to reboot the operating system. You do not disrupt user services and processes, as happens with static methods of device recognition.

Beginning with DIGITAL UNIX Version 4.0, DDR is preferred over the current, static method for recognizing SCSI devices. The current, static method, as described in System Administration, is to edit SCSI device customizations into the /sys/data/cam_data.c data file, reconfigure the kernel, and shut down and reboot the operating system.

Note

Support for the static method of recognizing SCSI devices will be retired in a future release of DIGITAL UNIX .

DIGITAL UNIX Version 4.0 supports both methods of recognizing SCSI devices. Both methods can be employed on the same system, with the restriction that the devices described by each method are exclusive to that method (nothing is doubly-defined).

The information DDR provides about SCSI devices is needed by SCSI drivers. You can supply this information using DDR when you add new SCSI devices to the system, or you can use the /sys/data/cam_data.c data file and static configuration methods. The information provided by DDR and the cam_data.c file have the same objectives. When compared to the static method of providing SCSI device information, DDR minimizes the amount of information that is supplied by the device driver or subsystem to the operating system and maximizes the amount of information that is supplied by the device itself or by defaults specified in the DDR databases.

You can also use DDR capabilities to convert customizations in the cam_data.c file to information in the DDR /etc/ddr.dbase text database.

For more information about DDR, see System Administration, ddr_config(8), and ddr.dbase(4).