[Contents] [Prev Chap] [*] [Next Sect] [Next Chap] [Index] [(i)]

8    Features and Interfaces Scheduled for Retirement

This chapter lists features of DIGITAL UNIX scheduled to be removed from, or changed in, future major functional releases. Users and developers should plan to migrate away from these features in the near future.


[Contents] [Prev Chap] [*] [Next Sect] [Next Chap] [Index] [(i)]

8.1    DECwindows Applications

The following DECwindows utilities and tools are scheduled for retirement in a future release of the DIGITAL UNIX operating system. These dx* tools and utilities, commonly known as DECwindows, have been replaced by the dt* tools in Common Desktop Environment (CDE) that were introduced in Version 4.0 of DIGITAL UNIX. The replacement applications are listed in Table 8-1. Not all of the dx* applications being considered for retirement have a replacement due to the limited use or capability of that specific tool/utility.

Table 8-1: DECwindows Applications to be Retired

Tools/Utilities to be Retired Replacement Option(s)
dxprint dtlp
dxmail dtmail,xmh,exmh,Netscape mail
dxcalendar dtcm
dxcalc dtcalc,xcalc
dxclock Front Panel,xclock
dxpaint dticon/dtstyle,bitmap
dxnotepad dtpad
dxbook dthelpview,Netscape
dxcardfiler N/A
dxsession xdm,dtsession
dxpause N/A
dxvdoc ghostview, Adobe Acrobat
CDA N/A

You should migrate to the dt* tools/utilities or other options as soon as possible.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.2    Adobe Display PostScript, Client Libraries, and X Server

Adobe has announced its intent to retire Display PostScript, which includes the client libraries and X Server extension. Therefore, DIGITAL will be retiring the Adobe Display Postscript (DPS) libraries and X Server in a future release of DIGITAL UNIX. No replacements will be available.

DIGITAL applications that use Adobe DPS are:

These applications will no longer be available after the retirement.

Customers who have used the Adobe DPS libraries to develop their own applications will not have a migration path. To lessen the severity of this problem, DIGITAL intends to package Adobe DPS in its own subset, which will be available as an unsupported option after the retirement of Adobe DPS in DIGITAL UNIX. DIGITAL also intends to provide a replacement viewer for documentation. Options are Ghostview, which currently ships on the DIGITAL UNIX Freeware CD, or Adobe Acrobat, which has been ported to DIGITAL UNIX.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.3    Nonconforming Curses Library

DIGITAL UNIX Version 4.0 included a new X/Open-Compliant Internationalized Curses library. This library was not binary compatible with previous versions of the DIGITAL UNIX Curses library, so compatible binaries (named libcurses.a and libcurses.so) were shipped in separate directories for Version 4.0. In that same release, DIGITAL announced the intent to put the compatible binaries into an obsolete subset and subsequently remove them in future releases.

These compatible binaries have been moved into the OSFOBSOLETE425 subset for Version 4.0D and will be removed in the next major release of DIGITAL UNIX.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.4    Previous C Compiler

The C compiler for DIGITAL UNIX will be officially replaced by DEC C for DIGITAL UNIX in the next major release of DIGITAL UNIX. Both compilers were available in DIGITAL UNIX Version 4.0 and both continue to be available in this release. However, in the next major release of DIGITAL UNIX, the C compiler for DIGITAL UNIX will not be distributed in the default subset and therefore will not be installed during a default installation. The licensing terms and conditions remain the same as they were in previous releases.

In this release, as in DIGITAL UNIX Version 4.0, the newer DEC C is the default compiler invoked using the cc command. In releases prior to DIGITAL UNIX Version 4.0, it was invoked using the following option:

cc -migrate

DEC C offers additional language and compiler features while also offering better, smaller, and faster executable files.

The older C compiler had been the default compiler for DIGITAL UNIX Version 3.2 and earlier. It remains available in this release, and is invoked using the following option:

cc -oldc

Refer to the cc(1) reference page or the Developers' Toolkit for DIGITAL UNIX Software Product Description for additional information.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.5    The dbx Debugger

The dbx symbolic debugger will be retired in a future release of DIGITAL UNIX. The dbx debugger will be replaced by the DIGITAL ladebug debugger, which is a superset of the dbx functionality. The DIGITAL ladebug debugger is command line compatible with dbx and also supports a graphical user interface.

DIGITAL recommends that you begin using the DIGITAL ladebug debugger now and report any problems. This will enable DIGITAL to provide a higher quality replacement when dbx is finally retired.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.6    DEC C Compiler Default Change from -std0 to -std

The default language mode for the DIGITAL UNIX C compiler will change from -std0 to -std. This will occur in a future release.

When the change occurs, it will be possible to revert back to -std0 by specifying -std0 on the compilation command line, by adding -std0 to the /usr/ccs/lib/cmplrs/cc/comp.config file, or by using an environment variable.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.7    Change in struct utmp, struct utmpx, and struct lastlog

To provide compliance with several UNIX and Internet standards, the utmp, utmpx, and lastlog structures will be changed in the next major release of DIGITAL UNIX. These changes will affect the /usr/include/utmp.h, /usr/include/utmpx.h, and /usr/include/lastlog.h files :

These changes will also affect the format of the /var/adm/utmp, /var/adm/wtmp, and /var/adm/lastlog files. Conversion programs will be supplied. The programs will allow you to convert your existing files to the new format or convert new format files to the old format for use by existing programs.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.8    C Language long double Type Changing to 128 bits

In a future release of DIGITAL UNIX, the default size of the C language long double type will change from 64 bits to 128 bits. This will allow application writers to perform mathematical calculations on numbers much larger in magnitude with more precision than possible with the current long double type, which is treated identically to the double type. A compiler option will be provided to allow existing source code that expects a 64-bit long double type to continue to be compiled and executed.

The one binary incompatability that an existing application (if linked using the -call_shared switch) could experience with the new default is related to the input and output of long double types. Currently, the printf and scanf functions, and other associated functions, interpret the format code %Lf (capital-L followed by f) as referring to a 64-bit long double type. In a future release, the interpretation of this format code will be changed to expect the new 128-bit data type. Programs that use this format code will either need to be changed, or will need to be run with the new compatibility library that will be provided. An extra step will be necessary to cause the application to use this library, and will be documented in the release in which the change actually takes affect.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.9    C Library Functions and POSIX P1003.1C

As of DIGITAL UNIX Version 4.0, the following C library functions exist in two versions due to conflicts between previous versions of DIGITAL UNIX and the recent IEEE POSIX P1003.1C standard (these new interfaces are in effect by default). The old interfaces are currently accessible by defining the C preprocessor symbol _POSIX_C_SOURCE to 199309L.

asctime_r     getgrnam_r    getpwuid_r    localtime_r   readdir_r
ctime_r       getlogin_r    gmtime_r      rand_r        ttyname_r
getgrgid_r    getpwnam_r

Binary compatibility is maintained in DIGITAL UNIX Version 4.0D; however, these routines will be retired in a future release of DIGITAL UNIX. The obsolete versions should not be used in new designs. These routines formerly resided in libc_r.a and libc_r.so, but were merged into the standard C runtime library.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.10    POSIX 1003.4a (draft 4) pthread Routines in DECthreads

The POSIX 1003.4a, Draft 4 interface of DECthreads will be retired in a future release of DIGITAL UNIX. Applications that were written using the POSIX 1003.4a, Draft 4 API should be migrated to the IEEE Std 1003.1c-1995, POSIX System Application Program Interface provided by DECthreads. The POSIX 1003.1c standard interface is the most portable, efficient, and powerful programming interface offered by DECthreads. A compatibility mode for the draft 4 POSIX 1003.4a API has been provided to help ease migration. This compatibility mode will be removed in a future release.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.11    DECthreads CMA Interface

The CMA interface of DECthreads is obsolete beginning with this release of DIGITAL UNIX. Obsolescence means that while the CMA API will continue to exist in DIGITAL UNIX and will be supported, CMA routines will no longer be documented or enhanced. DIGITAL recommends that you port your CMA based application to the IEEE Std 1003-1c-1995, POSIX System Application Program Interface provided by DECthreads.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.12    Asynchronous I/O Binary Compatibility

Data structures for asynchronous I/O, like aio_read() and aio_write(), changed between DIGITAL UNIX Version 3.2 and 4.0. The kernel currently handles these differences so that applications built under Version 3.2 continue to run when executed on Version 4.0x systems.

In the next major release of the operating system, support for applications built under Version 3.2x using asynchronous I/O will be discontinued. These applications will need to be recompiled and relinked in order to run properly under DIGITAL UNIX.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.13    Nemacs

Nemacs Version 3.3.2, a public domain Japanese implementation of emacs, will be retired in a future release of DIGITAL UNIX. Mule, a public domain multilingual implementation of emacs, will be carried forward as the replacement functionality for Nemacs. The Nemacs subsets IOSJPNEMACS425 and IOSJPNEMACSSRC425 will be removed from the system. For more information on Mule, refer to the mule(1) reference page.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.14    Berkeley Software Distribution TTY-NAME

The intent to retire the BSD TTY-NAME namespace was announced in DEC OSF/1 Version 3.0. The retirement will not be implemented in this release, but will be deferred to a later release.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.15    SCSI Device Names

Support for rz SCSI device names will be retired in a future release of DIGITAL UNIX. Any code that derives knowledge about a device from the ASCII name or minor number may be impacted.

All code that uses the current namespace will be compatible when the change occurs because a mechanism that ensures binary compatability will be provided. Existing interfaces such as names and minor numbers will be fully supported.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.16    The -x and -p Options in addvol and mkfdmn

The -x and -p options of the addvol and mkfdmn commands allow you to set the per-volume bitfile metadata table (BMT) when you create a new volume or file domain. Users typically set the BMT to prevent an "extent exhaustion problem" that is common in the field.

In Version 4.0D, DIGITAL has removed limitations in the operating system that caused the "extent exhaustion problem," hence the -x and -p options are no longer needed and will be retired in a future major release.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.17    LSM Block Change Logging (BCL)

In the next major release of DIGITAL UNIX, the Logical Storage Manager Block Change Logging (BCL) feature will be retired and replaced by a new logging method. This new logging method, called Dirty Region Logging (DRL), will log regions instead of blocks for writes to LSM mirrored volumes. For most environments, DRL will provide the same ability to quickly resynchronize mirrors after a failure as BCL, but with considerably less logging overhead.

The logging format and configuration for DRL will not be compatible with BCL; for example, DRL will require a log size of at least two blocks. The next major release of DIGITAL UNIX will automatically reconfigure volumes for DRL when a BCL mirrored volume has a log of two or more blocks. Mirrored volume configurations with a BCL of one block will require manual reconfiguration to continue to take advantage of logging for faster mirror recovery.

Due to these changes, DIGITAL recommends configuring a BCL size of two or more blocks to simplify BCL to DRL migration in the future. For optimum DRL configurations, use the following guidelines when configuring volumes with BCL: use a BCL subdisk block size of one block plus an additional block for every 1 GB of volume storage, then round up the BCL size to the next even number. Table 8-2 shows some examples.

Table 8-2: BCL Configuration Examples

Volume Size (GB) BCL Subdisk Size (Blocks)
<1 2
1 2
2 4
3 4
4 6
5 6
6 8
7 8
8 10
9 10
10 12


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.18    LSM volassist Command Syntax

In the next major release of DIGITAL UNIX, the syntax of the volassist command will be changing. It will no longer support the following constructs:


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.19    LSM volprint Command Format

In the next major release of DIGITAL UNIX, the default output format of the volprint command will be changing.

Invoking volprint with no options currently displays all objects in rootdg, starting with the rootdg disk group record, followed by all of the disk-media records, subdisk records, plex records, and finally volume records. In a future release, invoking volprint with no options will display all records for all disk groups, with all objects arranged in a hierarchical fashion.

Invoking volprint with an object-type option (v, p, or s) currently displays all objects of that type in the specific disk group. In a future release, invoking volprint with any of these options will display all objects of that type, as well as all objects of all subsidiary types, in all disk groups.

By default, invoking volprint currently displays the record type, name, association, kernel state, length, and comment field. In a future release, it will display the record type, name, association, kernel state, length, plex offset, state, and the tuti10 and puti10 fields.

Users who use volprint in scripts should use the -F option to define the exact output format that they require.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.20    LVM-to-LSM Migration Tools

The LVM-to-LSM Migration Tool was provided with DIGITAL UNIX Version 4.0 to enable migration from the LVM interfaces that were retired in that release to DIGITAL UNIX Logical Storage Manager volumes. This tool will become obsolete in later releases of DIGITAL UNIX because most customers will have migrated to LSM volumes by that time; therefore, DIGITAL plans to retire the LVM-to-LSM Migration Tool in a future release of the operating system.

There are no plans to retire UFS or the AdvFS Migration Tools at this time.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.21    OSF/Motif Version 1.1.3

The Motif Version 1.1.3 libraries have been provided as run-time services for compatibility with applications that have not yet converted to Motif 1.2. Development support was retired in DEC OSF/1 Version 2.0.

In DIGITAL UNIX Version 4.0 the Motif 1.1.3 libraries were moved to an optional subset. Applications that require the libraries will see an error from the loader and you must install the optional subset. This optional subset will be removed from the product in a future release.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.22    XIE Version 3.0 X Client Extension

DIGITAL UNIX Version 4.0D supports XIE Version 5.0. Support for XIE V3.0 Server extensions was removed in DIGITAL UNIX Version 4.0, but Client support will not be removed until a later release of DIGITAL UNIX.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.23    Microsoft Sound Board Driver

In DIGITAL UNIX V4.0, the device driver for the base audio on the DIGITAL AlphaStations and DIGITAL AlphaServers was removed from the base operating system. This device driver supported the Microsoft Sound Board (MSB), the AlphaStation Sound Card, and the built-in audio hardware shipped with certain AlphaStation systems.

The driver binaries are now available as part of the Multimedia Services for DIGITAL UNIX kit on the DIGITAL UNIX V4.0D Associated Products, Volume 1 CD-ROM in the MMEDRVMSB241 subset.

The following files will be removed from the base operating system:

You can also get support for this device from the Multimedia Services for DIGITAL UNIX kit that is located on the Software Products Library CD-ROM. Support is also factory-installed on all DIGITAL AlphaStation DIGITAL UNIX packaged systems. The license for this product is bundled with DIGITAL AlphaStations so that you can use it at no additional cost.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.24    Graph Utility

The /usr/bin/graph utility will be removed in the next major release of DIGITAL UNIX.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.25    The atmsetup Script

The atmsetup script is a new utility with DIGITAL UNIX Version 4.0D that allows you to set up or change the current configuration of ATM on your system.

This script was designed to be an interim solution to simplify the setup process for ATM. In future releases, it will be supplemented and finally replaced by an application in the SysMan suite, with a full graphical user interface.

For more information about how to use atmsetup, see the atmsetup(8) reference page and the Asynchronous Transfer Mode guide.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.26    Remote Prestoserve Support

In the next major release of DIGITAL UNIX, PrestoServe support for remote operations will be retired. This means that the use of the -h option of the presto command, the dxpresto hostname variable, and the -n option of the prestoctl_svc command will no longer be supported.

Users who require the ability to perform presto operations remotely can still do so by using telnet, rlogin, or rsh to gain access to a shell on the remote system and then to perform the operation locally.


[Contents] [Prev Chap] [Prev Sect] [Next Sect] [Next Chap] [Index] [(i)]

8.27    Disk Size Requirement for Installation

The minimum disk size requirement for installing the DIGITAL UNIX operating system is changing in the next major release due to additional features and services that are being added. The minimum disk size required to support a single-disk operating system installation will be 1 GB (such as an RZ26) for both default and custom installation types.


[Contents] [Prev Chap] [Prev Sect] [*] [Next Chap] [Index] [(i)]

8.28    Installupdate -i Option

The -i option to the /sbin/installupdate command will be retired in a future release of the operating system.

The -i option currently allows you to interactively select kernel components once the new software subsets have been installed. Starting with the next major release, this flag will be unnecessary because you will be able to interactively select optional kernel components at the beginning of the update installation process, prior to software installation. These kernel components will be built into the kernel automatically during the kernel build phase at the end of the update installation; therefore, you need not be present at that time.