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.
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.
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.
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.
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.
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.
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.
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.
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 :
struct utmp
will change from a
time_t
structure
to a
timeval
structure (to be consistent with
/usr/include/utmpx.h
).
ut_host
field size (in
struct utmp
and
struct utmpx
)
will be increased to comply with relevant Internet RFCs.
ll_line
and
ll_host
manifest constants in
/usr/include/lastlog.h
will change to allow their sizes to correspond to the
ut_line
and
ut_host
fields in
struct utmp
and
struct utmpx
.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
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:
[!]medianame,offset
You will still be able to use
[!]medianame,offset
,
but you will not be able to specify an offset. Users requiring the
ability to specify an offset will need to use the low-level commands
to create subdisks, plexes, and volumes exactly as required.
alloc=size
A new construct,
alloc=storage-spec[,storage-spec,...]
,
will replace
alloc=size
.
However, the new construct will not allow you to specify sizes for all
allocations. You will need to use the low-level commands to create
subdisks, plexes, and volumes exactly as required.
align=size
Two new constructs,
diskalign
and
nodiskalign
,
will replace
align=size,
allowing you to specify whether subdisks should be created on cylinder
boundaries. If you require the ability to specify alignments for all
allocations, you will need to use the low-level commands to create
subdisks, plexes, and volumes exactly as required.
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.
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.
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.
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.
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:
/usr/sys/BINARY/msb.o
/usr/sys/include/io/dec/eisa/msb.h
/usr/sys/include/io/dec/eisa/msb_reg.h
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.
The
/usr/bin/graph
utility will be removed in the next major release of DIGITAL UNIX.
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.
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.
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.
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.