![[Return to Library]](BOOKSHELF.GIF)
![[Contents]](TOC.GIF)
![[Previous Chapter]](REW.GIF)
![[Next Section]](NEXT.GIF)
![[Next Chapter]](FF.GIF)
![[Index]](INDEX.GIF)
![[Help]](HELP.GIF)
This chapter provides brief descriptions of features that are new to the Digital UNIX system in this release or have changed significantly from previous releases.
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:
| Window Management | Workspace Management | SessionManagement |
| Calendar | Calculator | MIME-capable Mail |
| Text Editor | Icon Editor | Terminal Emulator |
| Application Integrator | Print Queue Manager | Windowing ksh |
| Keyboard |
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:
This utility converts your dxmail folders to the conventional mail format used by CDE dtmail. If you plan to use the mailcv utility to convert your existing mail folders, back up the folders before converting them. Do not use the -d option with this version of the mailcv utility.
This utility converts a DECwindows Calendar, dxcalendar, database for use with CDE Calendar, dtcm.
![[Previous Section]](PREV.GIF)
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.
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.
This release provides a new Curses implementation that incorporates the following sets of programming interfaces:
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:
Gives clients the ability to use requests that are arbitrarily large, rather than being limited to the size restriction of the core protocol. This can result in a significant performance improvement for applications that use large requests.
Enables double buffering, using the new X Consortium standard.
Complete implementation of full XIE 5.0 protocol with a few exceptions.
See the following section.
The XKB (X Keyboard) server extension is new for X11R6 and for Digital UNIX Version 4.0. 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.
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.
The following new or changed commands and utilities are available in this release.
Mtools software is included in the OSFDOCTOOLS400 subset. In prior releases, the software was installed by an optional worldwide support subset.
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.
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.
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.
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.
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.
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.
The dxterm terminal utility has the following new features:
See the dxterm(1X) reference page for more information.
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.
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.
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. See the Release Notes for information on supported systems and current restrictions on use.
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.
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.
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 configuration applications modify system files that control various aspects of network connectivity and system configuration.
The daily administration applications manage users, file systems, remote hosts, licenses, and backup; one application assists you in shutting down the system.
The monitoring and tuning applications monitor processes and tune kernel parameters.
The storage management applications manage disk organization and performance.
The tools provide quick status reports.
The following sections list the system management utilities.
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.
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.
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.
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.
The following enhancements have been made to the installation procedure:
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.
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.
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:
The disk configuration utility, diskconfig, manages certain disk operations for the base system.
Use this application to:
The mail configuration utility, mailconfig, configures the sendmail utility.
Use this application to:
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:
The NFS configuration utility nfsconfig, manages the Network File System (NFS) and related processes on a host.
Use this application to:
The print configuration utility, printconfig, manages the printcap file, print daemon specific directories, and files.
Use this application to:
Internationalization configuration is available if the optional worldwide support subsets are installed. See Section 1.13 for more information.
There are eight applications for the daily administration of your system:
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.
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:
The input and output areas provide icon containers and user text areas. You can drag icons that represent files and directories from the CDE File Manager, or icons representing tape and floppy drives from the system information application. Any icon that you can drag can also be dropped into the input icon container. Type the name of a file, directory, or device into the user input text area.
The Archiver requires you to choose whether to use absolute or relative pathnames. The use of absolute pathnames (those written out in full with an initial slash) and relative pathnames (those written without an initial slash) allows the archiver to control the placement of retrieved files. Files in an archive have either absolute or relative paths. Files with relative paths are restored to the current default directory. That is, they are restored to the directory that is displayed in the default directory area.
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:
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:
The license manager utility, dxlicenses, provides access to Digital's License Management Facility (LMF).
This application allows you to:
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:
The system information utility dxsysinfo, displays and monitors system resources on a Digital UNIX system.
Use this application to:
The Audit Manager, dxaudit, allows you to create audit reports. For more information see the Security manual and the dxaudit(8) reference page.
The applications described in this section help you to monitor and tune your system.
The kernel tuner utility, dxkerneltuner, manages attributes of loadable kernel subsystems.
Use the kernel tuner to:
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.
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.
This release complies with many new and changes standards. Refer to the standards(5) reference page for more information.
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.
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.
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.
This release includes the following enhancements to the development environment.
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:
The following changes have beem implemented for DEC C++.
Refer to the DEC C++ Class Library Reference Manual for details on the threadsafe support, including a new Mutex Package.
The division routines within the Complex Library now catch divide-by-zero errors instead of signaling them.
For iostream assignment operators, there is no longer a memory leak when you use the *_withassign assignment operators to initialize an object for which you have called xalloc(). Previously, the memory allocated for the object by xalloc() was lost.
The String extraction operator now takes care of dynamically allocating the String to accommodate the input.
When you open a file specifying ios::ate but not ios::app to the filebuf open() function, the file is no longer opened in O_APPEND mode. This incorrect behavior caused all data to be written to the end of the file, regardless of the current file position.
Various problems with exception handling have been fixed. Also, support for exception handling in DEC C++ version 5.3 has been added.
When the Complex Library exp() function detects an underflow error, the resulting value is now (0,0) instead of (+/- max-float, +/- max-float).
A single application is restricted from using both the math library function clog() and the iostream package's clog object. This restriction is due to the fact that libm and libcxx each contain a definition for the global symbol clog and those definitions are incompatible.
Furthermore, applications which reference one of the clog symbols cannot include both -lcxx and -lm on their ld command line. An error will be generated by ld because clog is multiply defined.
The fstream, ifstream, and ofstream close() member functions now clear the stream's error state when the close succeeds. Call the clear() member function after the call to close().
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.
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.
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.
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.
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.
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.
Digital UNIX Version 4.0 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.
Digital UNIX Version 4.0 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.
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:
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:
Asynchronously writes changes in a file to permanent storage
Writes data changes in a file to permanent storage
The open function now takes the following new flags for synchronized I/O:
Ensures synchronized I/O data integrity of the file accessed
Used for synchronized I/O read operations
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.
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..
The following networking enhancements have been implemented.
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.
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.
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.
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.
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.
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.
The following new features were implemented:
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).
This release provides the following new enhanced security features.
See the Security manual and the setrlimit(2), edauth(8), and convuser(8) reference pages.
The following file system enhancements have been implemented in this release.
The following new features were introduced 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.
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.
ACLs (Access Control Lists) on files and directories are a new feature in this release. They are manipulated with the getacl and setacl commands.
The following features are available:
Digital UNIX Version 4.0 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:
For details, refer to the volunroot(8) reference page.
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.
In Digital UNIX 4.0, 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.
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.
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 mostnm,and 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 4.0, 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.
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.
To make all modules the same, a -dc linker switch was added to build modules. This has the effect of forcing a full declaration and storage allocation for all commons (globals). Previously, if two files both declared a global int foo;, the linker would coalesce them into the same symbol when linking the kernel. This still happens within a module, but not across modules. Each module would have its own declaration foo, resulting in multiple definitions of the same global. Because of the multiple definition, kernel linking would fail. To avoid this, make all but one declaration external, using the extern. variable declaration
The BINARY file is no longer configurable. All files that are listed as Binary are compiled, and placed into modules as defined. The BINARY configuration file no longer has any information about hardware configuration (bus, devices or controllers) or most options (such as CDFS or NTP_TIME). Neither are any of these header files built in BINARY. BINARY files that use the #include statement to include other files, and the substitution statement #define, will no longer compile. For example:
#include <device.h>
#define NDEVICE 4
This includes files that use the following inclusion statement:
#include <data/NotBinary_data.c>
See the doconfig(8) and sizer(8) reference pages for more information.
The following new features have been implemented to support internationalization.
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.
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.
The following new features have been implemented to support internationalization:
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.
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.
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.
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.
PCMCIA (PC Card) support is a new feature in this release and is limited to the following capabilities:
The following restrictions apply in this release.
and the SWAPBOX PREMIUM COMBO ... Model MMCD-FC2:
However, other ISA to PCMCIA bridge adapters using the Intel i82365SL or compatible chip may also work.
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.
>>>
isacfg -slot 1 -etyp 1 -dev 0 -mk -iobase0 3e0 -irq0 14 -enadev 1 -handle PCIC-PCMCIA
NOTE that if the system is already using slot 1, use other slot number that is not used.
type >>>init to use these changes
>>>isacfg -slot 1
============================================================= handle: PCIC-PCMCIA etyp: 1 slot: 1 dev: 0 enadev: 1 totdev: 1 iobase0: 3e0 membase0: 8000000000000000 iobase1: 8000000000000000 memlen0: 8000000000000000 iobase2: 8000000000000000 membase1: 8000000000000000 iobase3: 8000000000000000 memlen1: 8000000000000000 iobase4: 8000000000000000 membase2: 8000000000000000 iobase5: 8000000000000000 memlen2: 8000000000000000 rombase: 8000000000000000 romlen: 8000000000000000 dmamode0/chan0: 80000000 irq0: 14 dmamode1/chan1: 80000000 irq1: 80000000 dmamode2/chan2: 80000000 irq2: 80000000 dmamode3/chan3: 80000000 irq3: 80000000
============================================================= >>>
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
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
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.
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.
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.
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.
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).