DIGITAL UNIX ULTRIX to DIGITAL UNIX Migration Part Number: AA-PS3EE-TE December 1997 Product Version: DIGITAL UNIX This manual describes how to migrate from an ULTRIX and UWS system to a DIGITAL UNIX system. The manual covers the migration to DIGITAL UNIX Versions 3.0 to 3.2 from ULTRIX and UWS Versions 4.2 to 4.4 and to DIGITAL UNIX Version 4.0B from ULTRIX and UWS Version 4.5. The manual discusses migration issues for ULTRIX users, system and network administrators, and programmers.
© Digital Equipment Corporation 1997 All rights reserved. The following are trademarks of Digital Equipment Corporation: ALL–IN–1, Alpha AXP, AlphaGeneration, AlphaServer, AltaVista, ATMworks, AXP, Bookreader, CDA, DDIS, DEC, DEC Ada, DEC Fortran, DEC FUSE, DECnet, DECstation, DECsystem, DECterm, DECUS, DECwindows, DTIF, Massbus, MicroVAX, OpenVMS, POLYCENTER, Q–bus, StorageWorks, TruCluster, ULTRIX, ULTRIX Mail Connection, ULTRIX Worksystem Software, UNIBUS, VAX, VAXstation, VMS, XUI, and the DIGITAL logo.
Contents About this Manual Part 1 1 Introduction Introduction to Migrating from ULTRIX to DIGITAL UNIX Systems 1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 1.1.8 1.1.9 1.1.10 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.3 1.4 1.4.1 1.4.2 DIGITAL UNIX Features Unavailable on ULTRIX Systems . OSF/1 Kernel . . .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Real-Time Kernel .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. .
2 Overview of the DIGITAL UNIX User Environment 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 Differences in the DIGITAL UNIX DECwindows Interface .. . Differences in the DIGITAL UNIX Directory Structure . .. . .. . Differences in User Applications and Commands . . . .. . .. . .. . .. . Differences in Shells . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Differences in the C Shell .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Differences in the Korn Shell . .
4.8.1 4.8.2 4.8.3 4.8.4 4.8.5 4.8.6 4.8.7 4.8.8 4.9 4.10 4.10.1 4.10.2 4.11 4.11.1 4.11.2 4.12 4.13 4.14 4.15 4.15.1 4.15.2 4.15.3 4.16 4.17 4.18 5 DIGITAL UNIX Directory Structure .. . .. . .. . .. . . .. . .. . .. . .. . Differences in Creating a UNIX File System . . . .. . .. . .. . .. . Differences in Checking a UNIX File System . . . .. . .. . .. . .. . Differences in Mounting and Unmounting a File System Differences in Monitoring File System Use . .. . . .. . .. . .. . .. . Specifying Disk Quotas ..
Overview of the DIGITAL UNIX Programming Environment 6.1 Alpha Architecture .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 6.1.1 Data Representation . . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 6.1.2 Data Access . .. . .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 6.1.3 Data Alignment . . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 6.1.4 File Systems .. . .. .
6.10.3 Creating Locale-Specific Information .. . .. . .. . .. . . .. . .. . .. . .. . 6.10.4 The iconv Command .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 6.11 Event-Logging Software .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 6.12 Security . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 6.13 Curses Libraries .. . .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. .
7.4.2.2 7.4.2.3 7.4.3 7.4.4 7.4.5 7.5 7.6 7.6.1 7.6.2 7.6.3 7.7 7.8 7.9 8 Differences that Apply to the Default Mode .. . .. . .. . .. . Differences that Apply to Strict ANSI Mode . . .. . .. . .. . Differences Between DIGITAL UNIX C and DEC C .. . .. . Differences Between DIGITAL UNIX C and C on VAX Systems . . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Differences Between DIGITAL UNIX C and VAX C (vcc) Software . .. . . .. . .. . .. . .. . . .. . ..
B.5 B.6 B.7 B.8 B.9 B.10 B.11 B.12 B.13 B.14 B.15 B.16 B.17 B.18 C Changes in the fcntl.h File . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Changes in the fstab.h File .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Changes in the in.h File .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Changes in the ioctl.h and ioctl_compat.h Files . .. . . .. . .. . .. . .. . Changes in the langinfo.h File . . .. . .. . .. . . .. . .. . .. . ..
F.8 F.9 G Clipboard Names . . .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . Resource Manager Names . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . F–10 F–11 Migration from ULTRIX Version 4.5 to DIGITAL UNIX Version 4.0B New Features and Changes in ULTRIX and UWS Version 4.5 New Features and Changes in DIGITAL UNIX Version 4.0B Common Desktop Environment . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . CDE Video Tour . . .. . ..
DECthreads is Compliant with Final POSIX 1003.1c Standard Interfaces .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . G.7.2.1 ULTRIX Migration Issues . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . G.8 Development Environment . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . G.8.1 Tcl/Tk Availability . . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . G.8.1.1 ULTRIX Migration Issues . .. . .. . . .. . .. . .. . .. . . .. . .
G.11.1 Advanced File System . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . G.11.1.1 New Tuning Parameters for AdvFS .. . .. . .. . . .. . .. . .. . .. . G.11.1.2 AdvFS Now Supports Directory Truncation .. . .. . .. . .. . G.11.1.3 ULTRIX Migration Issues . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . G.11.2 File System Access Control Lists .. . . .. . .. . .. . .. . . .. . .. . .. . .. . G.11.2.1 ULTRIX Migration Issues . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . ..
7–1 Locations of Standard DIGITAL UNIX Header Files . .. . .. . .. . 7–3 7–2 Comparison of DIGITAL UNIX and ULTRIX Predefined Symbols for the cc Command . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 7–22 7–3 Compilation Options that Are Compatible with ULTRIX C on RISC Systems . . . .. . .. . .. . .. . . .. . .. . .. . .. . .. . . .. . .. . .. . .. . . .. . .. . .. . .. . 7–23 7–4 Compilation Options that Are Compatible with DEC C . .. . .. .
About this Manual This manual compares the DIGITAL UNIX operating system to the ULTRIX operating system by describing the differences between the two systems. This manual also contains information about software components of the DIGITAL UNIX product. _______________________ Note _______________________ This manual does not contain information about software components or products that you purchase separately from the DIGITAL UNIX product.
Chapter 3 Describes how to set up your DIGITAL UNIX user environment so that it is similar to your ULTRIX user environment. Also, it describes how to migrate shell scripts from an ULTRIX system to a DIGITAL UNIX system. Part III Migrating Your System and Network Administration Environment Chapter 4 Is an overview of the DIGITAL UNIX system and network administration environment that describes differences from the ULTRIX environment.
• General users – • • Technical Overview System and network administrators – Installation Guide – System Administration – Network Administration – Security – Sharing Software on a Local Area Network Programmers – Programmer’s Guide – Programming Support Tools – Writing Software for the International Market – Network Programmer’s Guide – Guide to Realtime Programming – Guide to DECthreads The printed version of the DIGITAL UNIX documentation set is color coded to help specific audi
Reader’s Comments DIGITAL welcomes any comments and suggestions you have on this and other DIGITAL UNIX manuals. You can send your comments in the following ways: • Fax: 603-884-0120 Attn: UBPG Publications, ZKO3-3/Y32 • Internet electronic mail: readers_comment@zk3.dec.com A Reader’s Comment form is located on your system in the following location: /usr/doc/readers_comment.
Conventions % $ A percent sign represents the C shell system prompt. A dollar sign represents the system prompt for the Bourne, Korn, and POSIX shells. # A number sign represents the superuser prompt. % cat Boldface type in interactive examples indicates typed user input. file Italic (slanted) type indicates variable values, placeholders, and function argument names. [|] {|} cat(1) In syntax definitions, brackets indicate items that are optional and braces indicate items that are required.
Part 1 Introduction
1 Introduction to Migrating from ULTRIX to DIGITAL UNIX Systems This chapter is an overview of migrating from the ULTRIX and ULTRIX Worksystem Software (UWS) operating system, Version 4.2 and higher, to the DIGITAL UNIX operating system, Version 3.0 and higher. It begins by describing some DIGITAL UNIX features that are unavailable on ULTRIX systems.
• Increased file system sizes The following sections describe these DIGITAL UNIX features in more detail. 1.1.1 OSF/1 Kernel The OSF/1 kernel is based on the Mach kernel developed at Carnegie-Mellon University. This kernel consists of a compact, extensible system kernel designed to support distributed and parallel computing services for single and multiprocessor systems. The OSF/1 kernel provides the basic operating system services, including virtual memory management and interprocess communications.
1.1.3 Standards Compliance Using programming standards enhances the portability of your application. Standard-compliant code is independent of the hardware or even the operating system on which the application runs. Both the ULTRIX and UWS system and the DIGITAL UNIX system have programming environments that allow you to develop applications that conform to the major industry standards.
application to use a different number of open file descriptors, see Section 8.3. 1.1.6 Logical Storage Manager The Logical Storage Manager (LSM) subsystem is a replacement for the Logical Volume Manager of previous DIGITAL UNIX systems. See Chapter 4 for more information. 1.1.7 Streams Kernel Mechanism System V Release 3.2 STREAMS is included in the DIGITAL UNIX system. STREAMS is a kernel mechanism that supports development of network services and data communications drivers.
SIA can be employed in base or enhanced security modes. By using the SIA routines, the security commands access a matrix.conf file. Which matrix.conf file is accessed depends on the security mode employed (basic or enhanced) and the security mechanisms that are enabled through SIA. This information is contained in the Security manual. In the DIGITAL UNIX system, SIA routines, through the appropriate matrix.
For complete information about user applications and commands, see Section 2.3 and Appendix A. The DIGITAL UNIX system provides three shells: the C shell (csh), the Bourne shell (sh), and the Korn shell (ksh). For information about how these shells compare to the ULTRIX equivalent shells, see Section 2.4. For information about migrating shell scripts, see Section 3.2. 1.2.2 Development Tools The DIGITAL UNIX development environment is similar to the ULTRIX development environment.
• CD-ROM (compact disc read-only memory) File System (CDFS) Conforms to the ISO 9660 standard. See cdfs(4) for more information. • Virtual File System (VFS) interface and framework The VFS interface enables transparent access to UFS and NFS file systems and allows both file systems to run in parallel. Transparent access is accomplished by retaining the traditional operating system interfaces on top of the VFS layer. Therefore, the file system types are not apparent to the user.
For more information about how the DIGITAL UNIX system and network management environment compares to the same environment on ULTRIX systems, see Chapter 4. 1.2.5 Data Interoperability In many cases, you can exchange data easily between DIGITAL UNIX and ULTRIX systems. For example, you can mount an ULTRIX file system on a DIGITAL UNIX system. (For information about performing this task, see Section 5.1.
1.3 ULTRIX Features Unavailable on DIGITAL UNIX Systems The DIGITAL UNIX system provides many ULTRIX features, but it omits some ULTRIX features.
commands and tools are the same or similar on the two systems. For information about the differences that do exist between the DIGITAL UNIX and ULTRIX user environments, see Chapter 2. The following list describes the major tasks involved in migrating from an ULTRIX to a DIGITAL UNIX system: • Using commands Most commands are similar on the DIGITAL UNIX and ULTRIX systems. For a list of specific differences between commands, see Appendix A.
unavailable or you need an operating version of the program while you are migrating source code, you can migrate an executable. 1.4.3.1 Migrating Source Code To migrate source code from an ULTRIX to a DIGITAL UNIX system, follow these steps: 1. Copy your program source files (and make files, if any) to the DIGITAL UNIX system. 2. If you require additional development environment tools to build your application, migrate those tools to the DIGITAL UNIX system. 3.
• Support applications that read system memory by using /dev/kmem or /dev/mem. • Support applications that depend on exact memory layout or file formats of system-provided files. • Translate ULTRIX executables older than ULTRIX Version 4.0. • Translate MIPS executables other than ULTRIX and DIGITAL UNIX Version 1.0 executables. • Translate big endian MIPS programs. • Provide precise exception behavior. • Emulate MIPS instruction atomicity.
Part 2 Migrating Your User Environment This part gives an overview of the DIGITAL UNIX user environment and describes specific differences between DIGITAL UNIX and ULTRIX systems that affect users.
2 Overview of the DIGITAL UNIX User Environment Using a DIGITAL UNIX operating system is similar to using an ULTRIX and UWS operating system. Like an ULTRIX and UWS system, a DIGITAL UNIX system offers both a windowing graphical user interface (GUI) for workstations and a terminal interface. Also like ULTRIX and UWS, the DIGITAL UNIX workstation interface is DECwindows, based on the industry standard OSF/Motif.
DECwindows interfaces: OSF/Motif and XUI. The OSF/Motif interface is almost identical to the DIGITAL UNIX system interface, because the ULTRIX and UWS implementation is based on OSF/Motif Version 1.2.2. The ULTRIX and UWS XUI interface is based on the DIGITAL developed graphical user interface. 2.2 Differences in the DIGITAL UNIX Directory Structure The directory structure on your DIGITAL UNIX system is different from the directory structure on an ULTRIX system.
2 3 4 The DIGITAL UNIX directory structure contains the /home directory. On DIGITAL UNIX systems, this directory is intended to be used to contain the home directories for users. For example, the home directory for a user named Ross might be /home/ross. See your system administrator for the actual location of your home directory. The DIGITAL UNIX directory structure contains the /sbin and /usr/sbin directories.
• Cardfiler The Cardfiler program for DIGITAL UNIX workstations has a user interface based on Motif, and is similar to the one on ULTRIX workstations. For information about using the Cardfiler program, see dxcardfiler(1X) or start the Cardfiler program and read its online help information. • CDA Viewer The CDA Viewer program on DIGITAL UNIX workstations has a user interface based on Motif, and is similar to the one on ULTRIX workstations. For information about using the CDA Viewer, see dxvdoc(1X).
• General-purpose commands Commands for searching files (such as grep), listing directory contents and moving between directories (ls, cd, and pwd), displaying the date and time (date), and so on are, in most cases, the same as the ULTRIX equivalent commands. Differences are noted in Appendix A. The ps command functions in either of the following two ways: – If you omit the minus sign before the option keywords (for example, ps x), the command functions like the BSD ps command.
• Reference pages Reference pages that describe the various DIGITAL UNIX commands are on line. You can read the references pages on line by using the man command, just as on an ULTRIX system. For example, enter the following command at your system prompt: % man man This command displays the man command’s reference page. The section numbers for some reference pages have changed. For example, on ULTRIX systems, Section 4 describes special files. On DIGITAL UNIX systems, Section 4 describes file formats.
The uucp command on DIGITAL UNIX systems differs from the uucp command on ULTRIX systems. The DIGITAL UNIX uucp command has some features that the ULTRIX uucp command does not have. The DIGITAL UNIX uucp command does not support the −W option. For more information about using the DIGITAL UNIX uucp command, see uucp(1). • talk command The talk command is the same as the ULTRIX talk command. For information about using the talk command, see talk(1).
language. The shell carries out commands either from a shell script or interactively from a terminal keyboard. In most respects, the DIGITAL UNIX C shell is the same as the ULTRIX C shell. In the DIGITAL UNIX C shell, you must set an environment variable to enable file name completion on a DIGITAL UNIX system and an environment variable to enable command-line editing. (For information about enabling file name completion, see Section 3.1.1. For information about enabling command-line editing, see Section 3.
• The shell determines whether the argument you specify to the built-in cd command is a subdirectory of any of the directories specified in the definition of the CDPATH environment variable. If the shell finds a subdirectory that matches the argument you specify, it changes your current directory to that subdirectory. The ULTRIX sh shell does not have this feature. • The default search path for the DIGITAL UNIX sh shell is /usr/bin. On the ULTRIX system, the default search path is :/bin:/usr/bin.
3 Migrating Your ULTRIX User Environment to a DIGITAL UNIX System This chapter describes how to set up your DIGITAL UNIX user environment so that it is similar to your ULTRIX user environment. This chapter also describes how to port shell scripts from an ULTRIX system to a DIGITAL UNIX system. 3.1 Setting Environment Variables In most cases, you can set environment variables on your DIGITAL UNIX system the same as you set them on your ULTRIX system.
3.1.1 Setting the C Shell filec and PATH Environment Variables The DIGITAL UNIX system C shell contains most features of the ULTRIX C shell. One difference between the two shells is that the ULTRIX C shell includes file name completion by default. On DIGITAL UNIX systems, you must set the filec environment variable to enable file name completion. To set the filec environment variable, enter the following command: % set filec You can include this command in your .
3.1.3.1 Setting the Environment Variable for Messages To display a message in your native language, a program reads the message from a message catalog. By default, your program searches the /usr/lib/nls/msg/%L /%N path for message catalogs. In the preceding pathname, %L represents the locale name specified by the LANG environment variable, and %N represents the name of the message catalog, which is usually similar to program_name.cat.
set codesets are not supported on DIGITAL UNIX systems. Therefore, the following locales are unavailable on DIGITAL UNIX systems: • ENG_GB.MCS • ENG_GB.646 • FRE_FR.MCS • FRE_FR.646 • GER_DE.MCS • GER_DE.646 On DIGITAL UNIX systems, locales are installed in the /usr/lib/nls/loc directory. For a list of available locales, see the Technical Overview. 3.2 Migrating Shell Scripts In most cases, your shell scripts will port from ULTRIX to DIGITAL UNIX with few modifications.
If your scripts contain explicit path references to commands that are in different directories on the DIGITAL UNIX system, you must change these references to reflect the DIGITAL UNIX locations. For more information about command differences that could affect porting your shell script from ULTRIX to DIGITAL UNIX, see Appendix A. 3.2.2 Migrating Korn Shell Scripts The Korn shell (ksh) is the same on DIGITAL UNIX and ULTRIX systems. You need not modify your shell scripts. 3.2.
The DIGITAL UNIX shell contains a built-in echo command. References to the echo command in a shell script that you run on a DIGITAL UNIX system invoke the built-in echo command. The ULTRIX Bourne shell contains no built-in echo command. References to the echo command in your ULTRIX shell script invoke the /bin/echo command. The DIGITAL UNIX built-in echo command differs from the /bin/echo command. For example, the built-in echo command does not support the −n option.
One significant difference between the ULTRIX sh5 shell and the DIGITAL UNIX sh shell is in their treatment of positional parameters when a function is called. The DIGITAL UNIX sh shell sets the positional parameters to the function call’s arguments as does the ULTRIX sh5 shell. However, the DIGITAL UNIX sh shell also saves the values the positional parameters held before the function was called. Upon return from the function, the shell sets the positional parameters to the saved values.
The && separator specifies that the command in braces ({}) is executed only if the test is true. 5 The mv command moves the /tmp/conv$$ file to the location of the original input file. In effect, this command writes the converted shell script over the input file. The shell script in Example 3–1 modifies only the first line in its input. You cannot use it to replace any sh5 invocation commands that appear on lines other than the first line of a shell script.
Part 3 Migrating Your System and Network Administration Environment This part gives an overview of the DIGITAL UNIX system and network administration environment, and describes specific differences between DIGITAL UNIX and ULTRIX systems that affect system and network administrators.
4 Overview of DIGITAL UNIX System and Network Administration The DIGITAL UNIX system and network administration environment is similar to the ULTRIX administration environment. You can use most administration tools on a DIGITAL UNIX system in the same way as on an ULTRIX system. However, some differences do exist. This chapter is an overview of the DIGITAL UNIX system and network administration environment, describing the differences from the ULTRIX environment.
others are optional. The contents of various DIGITAL UNIX subsets might be different from ULTRIX subsets. For information about the DIGITAL UNIX subsets, see the Installation Guide. The DIGITAL UNIX installation procedure creates log files that record the result of the installation. These log files are created in the /var/adm/smlogs directory. On ULTRIX systems, the log files are created in the /var/adm directory. 4.
Table 4–1: Setup Scripts Available on DIGITAL UNIX Systems (cont.) Setup Script Purpose svcsetup Modifying the name service configuration file, /etc/svc.conf uucpsetup Configuring your system for uucp connections 4.3 System Customization Files Both the DIGITAL UNIX and ULTRIX systems have files that you use to customize your system. You can use some of your ULTRIX customization files on your DIGITAL UNIX system with little or no modification.
• netgroup • networks • protocols • rpc • services Other configuration files are different on ULTRIX and DIGITAL UNIX systems. For example, the DIGITAL UNIX system does not have the following configuration files: • crontab Instead of using an /etc/crontab file, the directory /usr/var/spool/cron/crontabs contains a number of files that the cron daemon uses to start facilities. For more information, see cron(8). • rc.
4.4 System Configuration When you install the DIGITAL UNIX system, the distribution software includes the files that the system needs to create and build the core kernel and the kernel subsystems. You might need to reconfigure your system, on occasion, to align and tune it to meet the changing conditions of your site. The DIGITAL UNIX configuration procedure is similar in many ways to the ULTRIX procedure. The procedure consists of the Berkeley Standard Distribution Version 4.3 (BSD 4.
The DIGITAL UNIX system also contains more sophisticated security features. These features are described in the Security manual. 4.6 Print Services The DIGITAL UNIX system includes the traditional BSD UNIX capabilities for printing files. The system supports a print spooler for queuing print jobs to one or more printers. The /etc/printcap file describes the printers available, including their characteristics.
On a DIGITAL UNIX system, files to be printed are stored in a spooling directory. By default, the directory is named /var/spool/lpd/printername, where printername is the name of the printer. You can change the default spooling directory on a DIGITAL UNIX system by using the lprsetup utility. • Most ULTRIX print filters are available on DIGITAL UNIX systems. On ULTRIX systems, print filters are stored in the /usr/lib/lpdfilters directory. On DIGITAL UNIX systems, they are stored in the /usr/lbin directory.
• • • ln07rof LN07R ASCII to PostScript translation filter ln07rof_isolatin1 LN07R ASCII to PostScript translation filter with ISO Latin/1 encoding vectors ln07rof_decmcs LN07R ASCII to PostScript translation filter with the DEC Multinational character set encoding vectors ln08of LN08 (S) laser printer filter ln08rof LN08R ASCII to PostScript translation filter ln08rof_isolatin1 LN08R ASCII to PostScript translation filter with ISO Latin/1 encoding vectors ln08rof_decmcs LN08R ASCII to PostS
• A subroutine library that allows programs to query that database and make use of the capability values it contains This section describes database capabilities. Section 7.7 discusses using the curses and termcap libraries. The termcap capabilities in DIGITAL UNIX are comparable to those in BSD 4.3-5. The terminfo capabilities are comparable to those in System V Release 3.0 (SVID 2).
the Network File System (NFS). For information about configuring your type of file system (UFS or NFS), see the System Administration manual. Most commands you use to manage disks are the same on a DIGITAL UNIX system as they are on an ULTRIX system. This section compares disk and file system maintenance on the two systems, and points out differences. 4.8.1 DIGITAL UNIX Directory Structure The directory hierarchy on a DIGITAL UNIX system is different from that on an ULTRIX system.
3 The DIGITAL UNIX directory structure contains the /home directory, intended as a root for users’ home directories. However, on DIGITAL UNIX systems, the home directories for most users are subdirectories of the /usr/users directory, which is the default location for adding a user (typically, with the adduser command). The actual location of user subdirectories is at the discretion of the system administrator. 4 The /lib directory is a link to the /usr/lib directory.
The newfs command is similar on DIGITAL UNIX and ULTRIX systems. The DIGITAL UNIX command omits the −v option. For more information about newfs, see newfs(8). 4.8.3 Differences in Checking a UNIX File System To check the integrity of a UNIX File System (UFS), use the fsck command. The fsck command checks the integrity of UFS file systems. This command can determine the type of a particular file system by using information in the /etc/fstab file.
DIGITAL UNIX file system is contained on a separate line in the fstab file. The contents and field ordering of the line are different between DIGITAL UNIX and ULTRIX systems. On DIGITAL UNIX systems, you separate fields on a line with spaces or tabs. On ULTRIX systems, you separate fields by using a colon. See fstab(4) for more information. 4.8.5 Differences in Monitoring File System Use Use the df and du commands to monitor file systems use.
protocol. NFS Version 3 protocol does not have this file access limitation. NFS Version 3 protocol supports 64-bit remote file access. Therefore, the maximum file offset that can be accessed by Version 3 clients is 16 exabytes (2**64-1 bytes). Whether NFS Version 3 or Version 2 protocol is used is transparent to the client: no action needs to be taken. When a DIGITAL UNIX Version 3.0 client mounts a file system from a server, it will use the Version 3 protocol if the server supports it.
As on ULTRIX systems, the following four daemons implement the DIGITAL UNIX NFS service: • portmap The portmap daemon maps the remote procedure call (RPC) program numbers of network services to their Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port numbers. This daemon is similar on DIGITAL UNIX and ULTRIX systems. Like the ULTRIX portmap daemon, the DIGITAL UNIX portmap daemon supports port checking.
The disklabel command reads and writes the disk pack label. The disk pack label contains the partition table for the disk and information about the geometry of the disk. The disk label is located on one of the first sectors of the disk, usually in block 0. You use the disklabel command to create, modify, and display the label on a disk. This command is the equivalent of the chpt command on ULTRIX systems. For more information about the disklabel command, see disklabel(8). 4.
called ULTRIX Disk Shadowing. The ULTRIX Disk Shadowing product is not available on DIGITAL UNIX systems. To replicate data on a DIGITAL UNIX system, use the Logical Storage Manager (LSM) subsystem. 4.10.1 Logical Storage Manager The DIGITAL UNIX Logical Storage Manager (LSM) is an integrated, host-based disk storage management tool that protects against data loss and improves disk I/O performance.
Table 4–2: Differences in Disk Shadowing Facilities ULTRIX Disk Shadowing LVM Description A layered product that enables A kernel subsystem that you to replicate data on disk enables you to create and partitions. manage logical volumes. Additionally, you can replicate data and create logical volumes that span multiple disks.
You can install and use the DECnet software and any of its related software on a DIGITAL UNIX system. • Socket interface (both BSD 4.3 and BSD 4.4) and X/Open Transport Interface (XTI) to TCP/IP • STREAMS mechanism to support development of network services and data communications drivers The DIGITAL UNIX system does not support the packet filter pseudodevice driver.
You use the netsetup command to add your system to a local area network (LAN). This command is the same as the ULTRIX netsetup command, except that on a DIGITAL UNIX system, the netsetup command has additional features and a different interface. • netstat The netstat command displays network statistics, such as interface counters, protocol counters, and routing information. • netx This command is unavailable on DIGITAL UNIX systems. The DIGITAL UNIX system does not supply network exerciser software.
The screenmode command is the same on DIGITAL UNIX and ULTRIX systems. This command enables or disables packet screening by the kernel. • screenstat The screenstat command is the same on DIGITAL UNIX and ULTRIX systems. This command displays statistics about kernel packet screening. 4.11.2 Simple Network Management Protocol Agent The DIGITAL UNIX system employs the snmpd daemon as a Simple Network Management Protocol (SNMP) Agent.
• The configuration file entry has changed. On DIGITAL UNIX systems, the following is the configuration file entry for LAT: options LAT. • A setup script is available. You set up LAT on a DIGITAL UNIX system by using the latsetup command. This command creates the LAT terminal devices, adds entries into the /etc/inittab file, and starts LAT on your system. For more information on setting up LAT, see the Network Administration manual. • The name of the control program has changed.
the system supports the Berkeley Internet Name Domain (BIND) service, the Network Information Service (NIS), and the Network Time Protocol (NTP) Time Synchronization Protocol (TSP) time services. The DIGITAL UNIX system does not support the Kerberos authentication service. You cannot use Kerberos for password security, data encryption, or authentication services. It also does not support the Hesiod naming service.
The DIGITAL UNIX system has the bindsetup command, which allows you to configure your system as a BIND client or server. The DIGITAL UNIX system has the nslookup and nsquery commands to allow you to get host information from BIND. For information about these commands, see nslookup(8) and nsquery(8). 4.15.2 Network Information Services The Network Informtion Service (NIS) is a distributed database lookup service for sharing information between systems on a network.
/etc/rc.config file by using the /usr/sbin/rcmgr utility to automatically start the NIS daemons when the system boots. On ULTRIX systems, this is done by editing the /etc/rc.local file. The DIGITAL UNIX system also has commands, such as ypcat, ypmatch, and ypwhich, that allow you to get information from NIS. In addition, the system has commands, such as yppasswd and yppush, that allow you to maintain your NIS databases. These commands are the same on DIGITAL UNIX systems as they are on ULTRIX systems.
TSP is the protocol used by the /usr/sbin/timed daemon. In its simplest application, the TSP servers on a broadcast network (for example, an Ethernet) periodically broadcast TSP packets. The hosts on the network elect one of the hosts on the network running TSP as a master. The master then controls further operation until it fails and a new master is elected. The master collects time values from the other hosts and computes an average. Each host then synchronizes its clock with the master host.
4.17 The uucp Utility The DIGITAL UNIX system has the uucp utility for copying between UNIX systems. The uucp utility allows you to transfer data from one system to another, and to execute commands on a remote system. Connections using the uucp utility can handle data communication over a wider geographic area than a LAN and usually transmit the data through telephone connections. The uucp utility on DIGITAL UNIX systems is different in some ways from the uucp on ULTRIX systems.
On an ULTRIX system, information about systems that can access the local system is stored in the /usr/lib/uucp/USERFILE file, and information about which commands can be executed remotely is stored in the /usr/lib/uucp/L.cmds file. • System polling script The DIGITAL UNIX system has the Poll file, a script that polls named systems at certain intervals. This file is similar to the LIST.DAY, LIST.HOUR, LIST.LONGHALL, LIST.NIGHT, and LIST.NOON files in the /usr/lib/uucp directory on an ULTRIX system.
equivalent to the /usr/var/spool/uucp/STST directory on ULTRIX systems. The DIGITAL UNIX system has the /usr/spool/uucp/.Workplace directory, which is equivalent to the /usr/var/spool/uucp/TM directory on ULTRIX systems. The DIGITAL UNIX system has the /usr/spool/uucp/system_name directory, which is equivalent to the /usr/var/spool/uucp/sys directory on ULTRIX systems. For information about managing the uucp utility on DIGITAL UNIX systems, see the Network Administration manual.
5 Migrating Your ULTRIX System and Network Environment This chapter describes how to set up a DIGITAL UNIX system for maximum compatibility with ULTRIX systems, and how to migrate file systems from an ULTRIX system to a DIGITAL UNIX system.
2. Install the disk containing the ULTRIX file system onto the DIGITAL UNIX system. 3. Check the ULTRIX file system by using the fsck command: # /usr/sbin/fsck /dev/rrz0h ** /dev/rz0h ** Last Mounted On IMPOSSIBLE INTERLEAVE = 0 IN SUPERBLOCK SET TO DEFAULT ? The IMPOSSIBLE INTERLEAVE message indicates that the DIGITAL UNIX system cannot use certain information on the ULTRIX disk.
CD−ROM discs, use the −d option to the mount command. See mount(8) for more information. 5.2 Migrating Shadowed Data This section describes migration from the ULTRIX Disk Shadowing product to the DIGITAL UNIX Logical Volume Manager (LVM) software. _______________________ Note _______________________ This section does not discuss migration to the Logical Storage Manager (LSM) software on DIGITAL UNIX systems. For migration information about LSM, see the Logical Storage Manager manual.
maximum logical volumes, maximum physical volumes, and maximum physical extents in a volume group, which requires approximately 4 MB of additional disk space. 5.2.1 Migration Summary The following steps summarize the procedure for migrating shadowed data from an ULTRIX system to a DIGITAL UNIX system: 1. Dump the ULTRIX shadowed file system to tape. (This is the only step performed on an ULTRIX system.) 2. Label the disks that you intend to use for disk mirroring.
Mirror capacity: single mirrored Disk type: rz56 Use the following example as a guide for migrating your ULTRIX shadowed data: 1. Dump the ULTRIX shadowed file system to tape by entering the following command on your ULTRIX system: # dump 0uf /dev/rmt0h /fs This command copies the entire contents of the /fs file system to the /dev/rmt0h tape. The command also records the date of the dump in the file /etc/dumpdates when the dump is successful. 2.
This command creates the volume group special device file, which is a direct connection between the volume group and the LVM driver code. The volume group special device file must be a character (c) device; it must use one of three predefined major device numbers, in this case 16; and it must have a minor device number of 0. d. Create the volume group and populate it with the physical volumes you created with the pvcreate commands: # vgcreate /dev/vg01 /dev/rz1g /dev/rz2g Creating /etc/lvmtab.
This operation will take some time. Please wait... Logical volume "/dev/vg01/logvolmir" has been successfully extended. The -m option specifies that the system maintains one mirror of the data in logical volume /dev/vg01/logvolmir. The /dev/rz2g argument specifies that the system maintain the mirror using physical extents on the /dev/rz2g physical device. 5. Create a file system on the logvolmir volume by using the newfs command: # newfs /dev/vg01/logvolmir rz56 6.
file and the DIGITAL UNIX tar command reporting a checksum error. To read an ULTRIX tar archive spanning multiple tapes using the DIGITAL UNIX tar command, use the −U option on the DIGITAL UNIX system. This option allows the DIGITAL UNIX tar command to read tapes and to ignore the header information specific to ULTRIX. 5.
Parameter on ULTRIX Parameter on DIGITAL UNIX Remarks smmax shmmax Defines the maximum number of bytes of virtual memory at which a shared memory segment can be sized. The default value is 4 MB on DIGITAL UNIX systems. This value is expressed in pages on ULTRIX systems, and expressed in bytes on DIGITAL UNIX systems. smmin shmmin Defines the minimum number of bytes of virtual memory at which a shared memory segment might be sized. The default value is 1 MB on DIGITAL UNIX systems.
2. Create subdirectories in the /etc/nls directory. Programs search for the message catalogs in the /etc/nls/msg/%L directory, where %L represents the currently defined locale. You must create the msg/%L subdirectories. For example, suppose you want to use message catalogs for French as it is spoken in Canada. Enter the following commands to create subdirectories: % cd /etc/nls % mkdir -p msg/fr_CA.88591 3.
• SocketType, which is either a stream value or a datagram value. • ProtocolName, which is one of the protocols in the /etc/protocols file. • Wait/NoWait, which determines whether the inetd daemon waits for a datagram server to release the socket. (Stream sockets are always NoWait.) • UserName, which specifies the user name that the inetd daemon should use to start the server. • ServerPath, which specifies the full pathname of the server the inetd daemon should execute.
Part 4 Migrating Your Applications This part gives an overview of the DIGITAL UNIX programming environment and describes specific differences between DIGITAL UNIX and ULTRIX systems that affect the ways application programs are migrated to a DIGITAL UNIX system. This part also gives an overview of how to use shared libraries on a DIGITAL UNIX system.
6 Overview of the DIGITAL UNIX Programming Environment The DIGITAL UNIX and ULTRIX programming environments are similar and most of the tools in the DIGITAL UNIX programming environment are the same as the ULTRIX equivalent tools. However, some differences exist.
These changes, described in the following sections, can affect how a program accesses and manipulates data. 6.1.1 Data Representation The DIGITAL UNIX C data types have been modified and extended to include a 64-bit type. Table 6–1 shows the differences in data types between the ULTRIX and DIGITAL UNIX environments.
For instance, a multithreaded application or multiple processes that have access to adjacent byte data through shared memory or shared memory-mapped files will have to use thread mutual exclusion locking functions or semaphore locks, respectively, to avoid conflicts with accesses to adjacent byte or word data items. Also, the order in which write operations occur can be different from what the programmer intended.
UWS and DIGITAL UNIX system programming environments. However, the DECwindows XUI interface available on ULTRIX systems is different from the DIGITAL UNIX interface. The following sections discuss these differences. The DECwindows Motif programming environment provides libraries and tools for developing graphical applications for workstations.
• Name changes—For widget classes, functions, resources, enumeration literals, callback reasons, compound strings, and fontlists. See Appendix F for a list of the names for these components. • Window managers—Motif uses the Motif Window Manager (mwm); XUI uses the DECwindows Window Manager (dxwm). The window manager provides functions for moving and resizing windows on the workspace. The Motif Window Manager works with the toolkit to manage the operations of windows on the screen.
• Other programming tools, including ar, cflow, ctags, cxref, dis, file, lex, lint, make, nm, odump, pixie, prof, pixstats, size, stdump, strip, and yacc This section gives an overview of only the DIGITAL UNIX C preprocessor and C compiler, because they are part of the DIGITAL UNIX product. In addition, other compilers, such as DIGITAL Fortran and DIGITAL Pascal, are available for use on the DIGITAL UNIX system.
the compiler operates in by using one of the following command-line options: Option Description −std0 Invokes a mode that compiles C applications as defined by Kernighan and Ritchie (K&R), with some ANSI extensions such as function prototypes. This mode is the default mode. −std Invokes a mode that compiles applications according to the ANSI standard. The mode allows certain extensions to the ANSI standard, such as C++ style comments and casting of the left-hand side of an assignment operator.
6.3.3 The Linker In most instances, you can use the compiler to link separate application object files into a single executable application. As part of the compilation process, compiler drivers call the linker, ld, to combine one or more object files into a single application object file. The linker’s operation is essentially similar on the two systems; the most important difference is that by default the DIGITAL UNIX linker links with shared libraries; the ULTRIX system does not support shared libraries.
programmers. DEC FUSE offers a set of tools with a DEC OSF/Motif user interface and graphics options in an integrated setting. DEC FUSE tools include an editor, a code manager, a program builder, a debugger, a cross-referencer, and a call graph browser. DIGITAL UNIX systems also include another debugging tool, kdbx. The kdbx utility is an interactive, crash analysis and kernel debugging tool that replaces the ULTRIX crash program.
• file Reads one or more files as input, performs a series of tests on the files, and determines their types. • lex Generates a C language source file that matches patterns for simple lexical analysis of an input stream. • lint Checks C application files for coding that is inefficient, not portable, or might cause errors. For example, this command finds unreachable statements, automatic variables that are declared and not used, and logical expressions that have a constant value.
Strips the symbolic debugger information from an executable file. • yacc Converts a context-free grammar specification into a set of tables that can be used by a simple parsing program. 6.4 Source File Control Like the ULTRIX system, the DIGITAL UNIX system supports the Source Code Control System (SCCS). The DIGITAL UNIX system also supports the Revision Control System (RCS), which is an unsupported subset on the ULTRIX system.
Produces subset images, inventories, and control files from the input files that have been transferred from your source directory. The utility also generates data files that make up the media master in the output directory. This utility is the same on DIGITAL UNIX and ULTRIX systems. • setld Installs software on the user’s system.
libXaw.so libcda.so libips.so libXext.so libdnet_stub.so liblkwdxm.so libXie.so libdl.so libm.so libXm.so libdps.so libmach.so libXmu.so libdpstk.so libpsres.so libXt.so libdvr.so libpthreads.so libbkr.so libdvs.so libsys5.so The following shared libraries are also elements of all systems, but were not documented earlier in this manual: libXimp.so libXv.so libaud.so libcdrom.so libcmalib.so libcurses.so libiconv.so libmxr.so libproplist.so libsecurity.so libtli.so libxti.
only once on the disk. By contrast, if you link each process statically with a set of library routines, the image of the library routines occurs five separate times on the disk. • System memory savings When multiple processes run applications that are linked with a shared library, you save physical memory. As with disk space, you see the memory savings when multiple applications use the same shared library.
restrictions on using and creating shared libraries do exist. The following list describes these restrictions: • The /usr directory must be mounted when you run an application that is linked with shared libraries. If your application is designed to run when the /usr directory is not mounted, do not use shared libraries. When you link your application with shared libraries, your application executable does not include the shared library; it includes only information it needs to load the shared library.
6.7 Standard Application Programming Interfaces In addition to making your source code portable with respect to applicable language standards, you must make your applications conform to specific application programming interfaces (APIs) in order to link correctly and produce correct results. The DIGITAL UNIX system supports the following APIs: • Application Environment Specification (AES) AES is the specification to which OSF/1 Version 1.0 was built.
6.8 Network Programming Software The networking programming facilities available in the DIGITAL UNIX system provide a high degree of commonality and interoperability with the ULTRIX system. Both systems provide APIs, including X/Open Transport Interface (XTI), Data Link Interface (DLI), and sockets, as described in the following sections. In addition, DIGITAL UNIX provides support for STREAMS, which is compatible with System V Release 3.2 STREAMS. 6.8.
6.9 Distributed Services Programming Software This section discusses the following distributed services programming facilities: • Remote procedure calling (RPC) • Kerberos authentication service • Berkeley Internet Name Domain (BIND) service • Network Information Service (NIS, formerly YP) • Hesiod naming service 6.9.1 Remote Procedure Calling The ULTRIX system provides a general RPC mechanism, DEC RPC Version 1.
system will run on DIGITAL UNIX systems when using an ULTRIX server, as long as the ULTRIX system is Version 4.2 or higher. See Section 7.6.1 and Section B.18 for more information. 6.9.3 Naming Services The DIGITAL UNIX system supports both the Berkeley Internet Name Domain (BIND) service and the Network Information Services (NIS, formerly YP) service. Both of these services are interoperable between ULTRIX and DIGITAL UNIX systems.
into other languages. The message catalog system consists of message extraction tools, tools for translating messages, a tool for generating message catalogs, and routines for accessing message catalogs. 6.10.1.1 Message Extraction Tools (extract, strextract, and strmerge) Like the ULTRIX system, the DIGITAL UNIX system provides the extract, strextract, and strmerge commands that extract message text from your program and store it in a message text source file.
command is the same as the ULTRIX gencat command. The mkcatdefs command is the same on both systems. 6.10.1.4 Routines for Accessing a Message Catalog (catopen, catgets, and catclose) You use the DIGITAL UNIX catopen, catgets, and catclose library routines to open, read messages from, and close message catalogs. These routines are the same as the ULTRIX routines of the same names. By default, these routines search the /usr/lib/nls/msg/%L /%N path for a message catalog.
• LANG controls all categories of an application’s locale. However, you can override the setting of LANG by defining one of the environment variables that control a specific category ( LC_COLLATE, LC_CTYPE, and so on). • LC_ALL controls all categories of an application’s locale. Unlike LANG, you cannot override the setting of LC_ALL by defining one of the environment variables that control a specific category. • LC_COLLATE controls the collation category of the application’s locale.
By default, setlocale expects the locale-specific data to be in the language support databases contained in the /usr/lib/nls/loc directory (the /usr/lib/intln directory on ULTRIX systems). On ULTRIX systems, you can store the locale-specific data in a directory that is not in the default search path. You specify where the locale-specific data is by defining the INTLINFO variable. On DIGITAL UNIX systems you specify where the locale-specific data is by defining the LOCPATH variable.
6.12 Security The Security manual contains information about migrating a programming interface from ULTRIX to DIGITAL UNIX, including basic migration issues and ways to move ULTRIX authentication files to a DIGITAL UNIX system. The DIGITAL UNIX system does not support the functions for getting and setting authorization entries in the auth database. See the discussion of secauthmigrate in the Security manual for more information. Additionally, Section B.
7 Migrating Your ULTRIX Application to a DIGITAL UNIX System The best way to move your application from an ULTRIX system to a DIGITAL UNIX system is to migrate your source code to the DIGITAL UNIX system. When you port source code, the result is a native DIGITAL UNIX application that is easy to move to new versions of DIGITAL UNIX and new platforms. In addition, you can take advantage of DIGITAL UNIX features, such as 64-bit data types and addressing and shared libraries.
• Differences between ULTRIX and DIGITAL UNIX header files and routine definitions could require changes to your makefile. For information about these differences, see Section 7.2 and Appendix B. • By default, the DIGITAL UNIX compiler links your application with shared libraries. If you want to link your application with static libraries, specify the −non_shared option on the cc or ld command lines in the makefile.
The DIGITAL UNIX header files are kept in a directory hierarchy descending from the /usr/include directory. Table 7–1 lists most of the directories containing standard header files.
• Undefined symbol (a symbol that is not defined before its use) This message helps you to find references to header-file symbols that have moved or are no longer available: cfe: Error: file.c, line 8: ’ENOSYSTEM’ undefined, reoccurrences will not not be reported • Multiply defined symbol (a local definition that conflicts with a header-file definition): cfe: Warning: file.c:4: Tried to redefine the macro EDEADLK, this macro keeps the old definition in std/std1 mode, otherwise the macro is redefined.
• To generate a list of functions that your application needs, and to compile without allowing any library definitions on the command line when building your ULTRIX application, use the following command: % cc file_name.c -L Do not include any additional system -ldirectory options. The −L option inhibits ld from searching the standard directories for libraries. The ld command will issue messages identifying any unresolved symbols.
The following sections discuss each of these areas and the changes you must make to your program to take full advantage of the 64-bit environment, and to permit interoperability with 32-bit systems. 7.3.1 Pointers This section describes migration problems that some applications will encounter because they make assignments based on the assumption that pointers are the same length as int variables.
7.3.1.1 Controlling Pointer Size and Allocation The DIGITAL UNIX system has a set of compiler options and pragmas you can use to control pointer size and allocation, thereby allowing ULTRIX applications that may make assumptions about pointers being 32 bits to more easily migrate to a DIGITAL UNIX environment. The set of options for the cc command is known as the xtaso option.
time consuming. (To find pointer-to-int assignments in existing source code, use the lint −Q command.) Another way to overcome this problem is to use the Truncated Address Support Option (−taso option). The −taso option makes it unnecessary for the pointer-to-int assignments to be modified.
Figure 7–1 is an example of a memory diagram of programs that use the −taso and −call_shared options (and do not use threads). (If you invoke the linker (ld) through the cc command, the default is −call_shared. If you invoke ld directly, the default is −non_shared.
data segments, also causes shared libraries linked outside the 31-bit address space to be appropriately relocated by the loader.
• −T and −D options As previously noted, if the −T and −D options are used with the −taso option, the values that you specify for them will override the −taso option’s default values. Therefore, to avoid defeating the purpose of the −taso option, you must select addresses for the −T and −D options that are within the address range observed by the −taso option.
7.3.2 Constants Check the use of constants in your program, particularly if you are going to exchange data between 32-bit and 64-bit systems. Some constants might have different values between 32-bit and 64-bit systems, which might change the behavior of some operators. For example, hexadecimal constants are more likely to become long on DIGITAL UNIX systems.
comparison, an assignment, or a function call where the correct function prototype is in scope, standard C promotion rules will be in effect and the correct value will be assigned. To minimize assignment and argument errors in your code, use function prototypes because the number and type arguments are checked. 7.3.2.2 Integer and Long Constants—Shift Operations A bit shift operation on an integer constant will yield a 32-bit constant.
• Use typedef types in structures and set up the types as appropriate for the system. You can automatically do this by using information in the limits.h header file. • Be careful when building unions between the int and pointer data types, because they are not the same size. 7.3.3.2 Member Alignment Members of structures and unions are said to be aligned on their natural boundaries.
No additional padding (beyond 4 bytes of tail padding) is necessary because CountedString will naturally align on a quadword boundary. struct { char *text; int count; }CountedString; In the following example, the inclusion of CountedString as a member in the definition forces the alignment of the beginning of the structure to be on a quadword boundary. Additional padding might be introduced (depending upon the value of MAX_LINE) to ensure proper quadword alignment for the structure member, string.
7.3.4 Variables The 64-bit DIGITAL UNIX environment also changes assumptions about how you declare your variables, and how you use them in assignments and in function arguments. 7.3.4.1 Declarations To enable your application to work on both 32-bit and 64-bit systems, check your int and long declarations. If you have specific variables that need to be 32 bits in size on both ULTRIX MIPS and Alpha systems, define the type to be int.
• Do not freely exchange pointers and integers. Assigning a pointer to an int, assigning back to a pointer, and dereferencing the pointer may result in a segmentation fault. For example, avoid assignments similar to the following: int i ; char *buffer; buffer = (char *)malloc(MAX_LINE) i = (int)buffer; buffer = (char*)i; Use the lint −Q command to find these pointer-to-int assignments. If special steps are taken, pointer-to-int assignments can be retained without causing addressing problems.
Replace this coding with a union declaration. Be thorough when migrating this type of code to a 64-bit system, because the interdependencies and incompatibilities between these two structures might be difficult to find. • Examine all assignments of a long to a double as this can result in a loss in accuracy. On a 32-bit system, code can assume that a double contains an exact representation of any value stored in a long (or a pointer).
(varargs.h) mechanism. See varargs(3) for more information on the use of these macros. Programs written using varargs that expect the va_list type to be a pointer, or that make assumptions about the stack layout of a routine’s arguments, are nonportable. Such programs must be modified to correctly use the varargs(3) mechanism. Failure to do so will give compile-time errors, or incorrect run-time results. See varargs(3) for more information. 7.3.
7.3.5.2 The malloc and calloc Functions Memory allocation library functions such as malloc() guarantee to return data aligned to the maximum alignment of any object. In the 64-bit DIGITAL UNIX environment, malloc() returns a pointer to memory that is at least quadword aligned. 7.3.5.3 The lseek System Call When calling the lseek() system call to set the current position in a file, use the off_t type defined in types.h for the file offset.
different hardware platforms, different operating systems, and different programming environments. On DIGITAL UNIX systems, the _ _STDC_ _ symbol is defined as follows: • When you use the −std0 option, the _ _STDC_ _ symbol is undefined. (The −std0 option compiles code as defined by Kernighan and Ritchie (K&R) C.) • When you use the −std option, the _ _STDC_ _ symbol is 0. (The std option compiles code as specified by the ANSI C standard. This option also allows some extensions to the ANSI C standard.
Table 7–2: Comparison of DIGITAL UNIX and ULTRIX Predefined Symbols for the cc Command Name for −std and Name for −std0 −std1 Modes Mode Name for ULTRIX on RISC Systems Name for ULTRIX on VAX Systems String containing the host hardware name: _ _alpha _ _alpha _ _host_mips_ _ vax String containing the target hardware name: _ _alpha _ _alpha mips vax String containing the operating system name: _ _osf_ _ _ _osf_ _ unix unix _ _unix_ _ _ _unix_ _ ultrix ultrix unix bsd4_2 bsd4_2 String in
example, the DIGITAL UNIX compiler might issue errors or warnings in cases for which the ULTRIX compiler does not. To minimize the effect of these differences, use the DIGITAL UNIX compiler option that provides the most compatibility, as shown in Table 7–3. Table 7–3: Compilation Options that Are Compatible with ULTRIX C on RISC Systems If You Use This ULTRIX Option Use This DIGITAL UNIX Option Default — K&R C with ANSI extensions. Default (−std0)—K&R C with ANSI extensions.
• The DIGITAL UNIX C compiler does not allow you to modify a type you create with the typedef statement. For example, the following statement is invalid on DIGITAL UNIX systems: typedef int account; . . . account monthly; unsigned account display_account; To achieve this effect on DIGITAL UNIX systems, you must create both a signed and unsigned type, as shown: typedef int account; typedef unsigned int display_variable; . . .
• The DIGITAL UNIX C compiler does not allow you to specify #if directives within a macro call. Move #if directives outside of macro calls. • The DIGITAL UNIX C compiler requires you to use braces ({ }) in initializers more precisely than the ULTRIX C compiler. For example, the following initialization is valid on ULTRIX systems: struct S {char i[10]; int j} y = {{"aeiou", 1}}; The DIGITAL UNIX C compiler issues an error message in response to the preceding initialization.
The ULTRIX compiler allows you to use a partial string in a macro definition, as shown: #define abc "123 You can use this definition in a printf statement, as follows: printf(abc 456"); The output from this printf statement is the following: 123 456 To get the same effect on a DIGITAL UNIX system, use the following definition and printf statement: #define abc "123" printf(abc " 456"); • On DIGITAL UNIX systems, you can use recursive macro definitions when you specify the −std0 option.
Remove all empty declarations from your program. • You cannot cast the left-hand side of an assignment statement on DIGITAL UNIX systems. You must remove any such casts. On ULTRIX systems, you can cast the left-hand side of an assignment statement, so long as the result of the left-hand side is the same size as the result of the right-hand side. • On DIGITAL UNIX systems, each identifier declaration must contain either a type or a storage class.
7.4.3 Differences Between DIGITAL UNIX C and DEC C When you compile an application on a DIGITAL UNIX system that is compiled with DEC C on an ULTRIX system, you should notice few differences in how the program is compiled. Both compilers comply with the ANSI C language definition. However, you might notice some differences that result from implementation-specific features, standards-compatible extensions, or differences in interpretations of the ANSI standard.
• The DIGITAL UNIX C compiler supports only predefined macros that begin with two underscore characters ( _ _) when you use the −std option. Macro names that do not begin with two underscore characters are valid when you use the default compilation mode of the DEC C compiler. • The DIGITAL UNIX C compiler does not support the VAX C (vcc) compatibility mode keywords, language interpretations, or extensions. See Section 7.4.
• The varargs function on RISC systems is different from that function on VAX systems. Your application will fail if it walks an argument list by incrementing the address of an argument, particularly if the arguments are double-precision values. Use the macros in varargs.h when you use functions that have a variable number of arguments. Compiling with the −varargs option on RISC systems causes the compiler to detect nonportable code.
indicate that symbols are defined more than once. The cc compiler on VAX systems allows you to specify the same source or object file twice. • By default, the DIGITAL UNIX C compiler links your application with shared libraries, instead of archive libraries. If you want your application to be linked with archive libraries, use the −non_shared option. For more information, see Section 8.1. • The DIGITAL UNIX cc command uses a different syntax for the asm pseudofunction call.
7.4.5 Differences Between DIGITAL UNIX C and VAX C (vcc) Software If you compile an application you wrote for the cc compiler on VAX ULTRIX systems with the DIGITAL UNIX C compiler, you might notice some differences in how the compilers operate. Some of these differences are hardware specific, others are differences in how the compilers are implemented. To minimize the effect of these differences, use the DIGITAL UNIX C compiler option that offers the most compatibility, as shown in Table 7–6.
– _align – globaldef – globalvalue – noshare – readonly – variant_struct – variant_union • The DIGITAL UNIX C compiler does not support the main_program option. On VAX ULTRIX systems, this option allows you to give the main function a different name. • To be compatible, DIGITAL UNIX C structure and union types must be identical. The vcc compiler treats structure and union types as compatible if they are the same size in bytes. The types need not be identical to be compatible.
• The DIGITAL UNIX Version 2.0 and earlier systems support two levels of profiling that you use by running the postprocessor pixie utility. Profiling on VAX systems has two levels that you select with the −p and −pg options. The DIGITAL UNIX Version 3.0 system supports these two levels of profiling as well as the pixie utility. • The DIGITAL UNIX C compiler supports five levels of optimization, which are controlled by using the −O option.
Be aware that if you never used lint on your ULTRIX application, it might give you quite a bit of information about your DIGITAL UNIX application, some of which will not be pertinent to the problems with porting your application. For more information about using lint, see lint(1). 7.6 Linking Your Program Use the cc compiler to link your application. The linker reports errors caused by routines that do not exist on a DIGITAL UNIX system or by global symbols that are undefined.
You might need to link your application with one of these libraries if it depends on the behavior of a BSD or System V library routine. 7.6.1 Changes in Libraries The following list summarizes differences between ULTRIX and DIGITAL UNIX system libraries: • Merger of libraries into the libc library Unlike ULTRIX systems, the internationalization library, libi.a, the POSIX library, libcP.a, and the System V library, libcV.
You must remove calls to routines in these libraries from your application if you want to compile it on a DIGITAL UNIX system. Also, be sure to omit references to these libraries from the command line you use to build the application. 7.6.2 ULTRIX BSD Compatibility Library The DIGITAL UNIX system provides the libbsd.a library to allow you to use library routines that are compatible with ULTRIX BSD library routines. Table 7–7 lists the routines in the library and describes the BSD compatibility they offer.
Table 7–7: Routines in the ULTRIX BSD Compatibility Library (cont.) Routine Name Compatibility int rand() void srand(u_int seed) The rand() routine returns a number in the range of 0 to 231 −1. The srand() routine provides a seed for the random number generator. char *re_comp(char *) Converts a string into an internal form suitable for pattern matching. Returns 0 if the string was compiled successfully; otherwise, returns a pointer to an error message.
Table 7–7: Routines in the ULTRIX BSD Compatibility Library (cont.) Routine Name Compatibility MINT * xtom(char *key) char * mtox(MINT *key) void mfree(MINT *a) Provided for BSD compatibility for performing arithmetic on integers of arbitrary length. int wait(union wait *) Provides a wait call whose status_location parameter is of type union wait *. 7.6.3 System V Compatibility Library The DIGITAL UNIX system provides the libsys5.
Table 7–8: Routines in the System V Compatibility Library (cont.) Routine Name Compatibility pid_t setpgrp(void) If this call is successful, it returns the new process identification (PID). void (*signal(int, int(*func()) )) The specified signal is not blocked from delivery when the handler is entered, and the disposition of the signal reverts to SIG_DFL when the signal is delivered.
Table 7–9: Terminal Capability Differences (cont.) If You Use this ULTRIX Option Use this DIGITAL UNIX Option Library Used by C Compiler −lcursesX −lcurses X/Open curses library (System V Release 3 curses and terminfo functions on a DIGITAL UNIX system) −lcurses −D_BSD −lcurses BSD 4.2 curses library (BSD 4.3-5 curses functions on a DIGITAL UNIX system) In addition, the /usr/include/cursesX.h header file is replaced by /usr/include/curses.
The POSIX-conformant definition of getpgrp on DIGITAL UNIX systems states that getpgrp is called without arguments and returns the process group of the current process: pid_t = getpgrp(); The ULTRIX system’s mechanism for setting a process’s group ID is: void = setpgrp(int, int); This system call is supported on DIGITAL UNIX systems for compatibility only.
#include #include . . . int buf[2], val, arg; . . . /* Do not print the warning to the user */ buf[0] = SSIN_UACPROC; buf[1] = UAC_NOPRINT; error = setsysinfo(SSI_NVPAIRS, buf, 1, 0, 0); . . . /* Do not print the warning and deliver a SIGBUS signal */ buf[0] = SSIN_UACPROC; buf[1] = UAC_NOPRINT | UAC_SIGBUS; error = setsysinfo(SSI_NVPAIRS, buf, 1, 0, 0); . . . • On ULTRIX systems, the catopen routine opens a message catalog and returns a catalog descriptor if successful.
(void) ioctl(fd, TIOCSCTTY, 0); • The manner for establishing and controlling modem connections is different for DIGITAL UNIX and ULTRIX systems. The DIGITAL UNIX system uses POSIX conventions for modem control. Information about a serial line can be inspected and altered in the POSIX termios structure, using the tcgetattr() and tcsetattr() library routines. On ULTRIX systems, modem control was accomplished using the TIOCCAR, TIOCNAR, and TIOCWONLINE requests to the ioctl() system call.
need device information to specify a transport provider. In the DIGITAL UNIX system, this information must be present because XTI is implemented using the xtiso pseudostreams driver. You must change all your t_open calls to reflect this change for both TCP and UDP transport providers or change your application to determine the end point at run time. For example: #ifdef _ _osf_ _ t_open ("/dev/streams/xtiso/tcp", ...) #else t_open ("tcp", ...) #endif • On ULTRIX systems, XTI is layered on sockets.
8 Postmigration Programming Features After you migrate your source code from an ULTRIX to a DIGITAL UNIX system, you might want to enhance it by using features of the DIGITAL UNIX system. This chapter gives an overview of using three DIGITAL UNIX features: shared libraries, semaphores, and the number of open file descriptors. For complete information on using DIGITAL UNIX features, see the Programmer’s Guide. 8.
/usr/person. To link with that library, use the −l and −L options, as shown: % cc -o hello hello.c -L/usr/person -lspecial_math To link the application that does not use shared libraries, you must specify the −non_shared option in the cc command line, as shown: % cc -non_shared -o hello hello.
searches all of the directories a second time for a static (an archive) library (an .a file). When you develop applications, you might work with private shared libraries that are contained in directories other than the /usr/shlib directory. In this case, use the −L option to specify these directories. Before you execute the program, set the LD_LIBRARY_PATH environment variable to point to the directory containing the private shared libraries.
Now, suppose you enter the same command, but use the shared library instead of the archive library: % cc program1.o -lspecial_math program2.o This command succeeds, but prints a warning message indicating that the symbol is undefined. To correctly link this application, enter the following command: % cc program1.o program2.o -lspecial_math In general, always specify the −l option last in the command line. 8.1.2.
program1.o: project.h cc -c program1.c 8.1.4 Creating Shared Libraries from Object Files To create a shared library: 1. Create one or more source files that define the routines you want to include in the library. 2. Compile the source file into an object file, as shown: % cc -c special_math.c 3. Create the library by using the ld command. (You cannot use the cc command to create a shared library. You must invoke the ld command directly.
In this example, the −all option tells the linker to link all objects from the old.a archive library. The −none option tells the linker to turn off the −all option. The −no_archive option applies to the resolution of the −lc option, but not to old.a, since it is explicitly mentioned. 8.1.6 Optimizing Application Startup when Using Shared Libraries Your application starts more efficiently if your shared libraries can be loaded at a preassigned starting address in virtual memory.
The following list describes the procedure you follow to use the −update_registry option with the system’s /usr/shlib/so_locations file: 1. Copy the system’s so_locations file to your local area: % cp /usr/shlib/so_locations . 2. Give yourself write access to the file: % chmod +w so_locations 3. Create the shared library and use the −update_registry option: % ld -shared -no_archive -update_registry \ ./so_locations -o libspecial_math.so \ special_math.o -lc 4.
8.3 Using File Descriptors On both the ULTRIX and UWS and the DIGITAL UNIX systems, the number of open file descriptors a process can use is configurable. By default, the number for DIGITAL UNIX systems is 4096; on ULTRIX systems the default is 64. Your system administrator configures the number of open file descriptors. For information about configuring this number, see the System Administration manual.
Part 5 Appendixes This part contains appendixes that describe: • The differences between specific DIGITAL UNIX and ULTRIX commands (Appendix A) • The differences between specific DIGITAL UNIX and ULTRIX header files and routines (Appendix B) • The differences between specific DIGITAL UNIX and ULTRIX system calls (Appendix C) • The differences between ULTRIX and DIGITAL UNIX system terminal modem control (Appendix D) • The differences between the Motif and XUI graphical user interfaces (GUIs) (Appen
A Differences Between DIGITAL UNIX and ULTRIX Commands This appendix describes the differences between DIGITAL UNIX commands and ULTRIX commands. In some cases, the difference is that an ULTRIX command does not exist on a DIGITAL UNIX system. Other differences are caused by the options provided for a command being different or by some difference in the arguments to a command. For example, the DIGITAL UNIX command might expect a different name for a particular argument than the ULTRIX command.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System biod Not supported. Use the nfsiod command. bootparamd Not supported. No DIGITAL UNIX equivalent. catman The catman command automatically processes source reference pages by using tbl, neqn, and nroff −Tlp −h. It does not process through col.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System csh No hashstat built-in command. No DIGITAL UNIX equivalent. No CSHEDIT environment variable. Use the editmode variable. ctrace Not supported. Use the dbx debugger. dms Not supported. No DIGITAL UNIX equivalent. drtest Not supported. No DIGITAL UNIX equivalent. dupterm Not supported. No DIGITAL UNIX equivalent. edauth Not supported. Auditing not supported. elcsd Not supported. Use the syslogd daemon.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System No dstaddr parameter. Use the dest_address parameter. install Derived from System V Version For an installation program 3 install program. that has the BSD install program behavior, use the installbsd command. ipcs No -C option. No DIGITAL UNIX equivalent. No -N option. No DIGITAL UNIX equivalent. kdb_destroy Not supported. Kerberos not supported. kdb_edit Not supported. Kerberos not supported. kdb_init Not supported.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System No Ddatatype option. No DIGITAL UNIX equivalent. Translating ASCII, ReGIS, or TEKTRONIX data into PostScript data is not supported. Displaying messages from a PostScript printer is not supported. Embed PostScript commands in the PostScript file to allow data translation or to display messages from a printer. lpx Not supported. No DIGITAL UNIX equivalent. ls The −l option displays the group by default.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System mktemp Not supported. No DIGITAL UNIX equivalent. mop_mom Not supported. Supported in the DECnet/OSI for DIGITAL UNIX product. more Does not pass Escape sequences by default. Specify the −v option. The default number of lines Use the −n option to override displayed is k−1 instead of k−2. the default. Does not allow hyphens in the MORE environment variable. Remove all hyphens and spaces from the MORE environment variable.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System page The default number of lines displayed is k instead of k−1. Use the −n option to override the default. passwd No -a option. No DIGITAL UNIX equivalent. pc Not supported. No DIGITAL UNIX equivalent. However, you can purchase a Pascal compiler separately from the DIGITAL UNIX system. pdx Not supported. Use the dbx debugger. pg See ex.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System remnode Not supported. Supported in the DECnet/OSI for DIGITAL UNIX product. rmauth Not supported. Auditing not supported. routed No Simple Network Management Protocol (SNMP) support. Use the gated routing daemon. rsh5 Not supported. Use the Rsh shell. No -n option. No DIGITAL UNIX equivalent. No -d option. No DIGITAL UNIX equivalent.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System sh5 Not supported. Use the sh shell. Additionally, the DIGITAL UNIX sh command determines whether the argument to the built-in cd command is a subdirectory of any of the directories specified in the CDPATH environment variable. The shell changes your current directory to the first subdirectory that matches the argument. shexp Not supported. No DIGITAL UNIX equivalent. snapcopy Not supported. No DIGITAL UNIX equivalent.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System The −s option tells tar to strip Use the −S option to specify the number of 512-byte blocks. off leading slashes from pathnames instead of specifying the number of 512-byte blocks. tek4014_ps Not supported. No DIGITAL UNIX equivalent. test The -f option determines whether a file exists and is a regular file. Use other options to emulate the ULTRIX test command as described in Section 3.2.1. timed No -E option.
ULTRIX Command Differences on a DIGITAL UNIX Use this Instead System vcc Not supported. vi The ULTRIX ex editor uses the The DIGITAL UNIX ex editor termcap database. uses the terminfo database. wait Not supported. Use the /bin/sh built-in wait command. xget Not supported. Secret mail not supported. xlator_call Not supported. No DIGITAL UNIX equivalent. xsend Not supported. Secret mail not supported. zic Not supported. No DIGITAL UNIX equivalent. Use the cc command.
B Differences in ULTRIX and DIGITAL UNIX Header Files and Library Routines A number of system header files are different between the DIGITAL UNIX and ULTRIX systems. In some cases, an ULTRIX header file is unavailable on DIGITAL UNIX systems. Some differences between DIGITAL UNIX and ULTRIX header files are in the definitions of constants. Some constants that are defined on ULTRIX systems are undefined on DIGITAL UNIX systems; other constants have different values on DIGITAL UNIX and ULTRIX systems.
The DIGITAL UNIX system does not provide the creatediskbyname routine. You must remove references to that routine from your application. B.3 Changes in the dli_var.h File The dli_var.h header file defines constants and structures used by Data Link Interface (DLI) applications. The file is named /usr/include/dli/dli_var.h on DIGITAL UNIX systems. In addition, the sockaddr_dl structure contains the following new field, beginning in the first byte: u_char dli_len; B.4 Changes in the errno.h File The errno.
See intro(2) for a list of DIGITAL UNIX errno definitions. B.5 Changes in the fcntl.h File The /usr/include/fcntl.h file on ULTRIX systems includes the /usr/include/sys/file.h file. On DIGITAL UNIX systems, the included file is named /usr/include/sys/fcntl.h, and it contains a different set of definitions. If your application needs the definitions in /usr/include/sys/file.h, you must include that file explicitly. B.6 Changes in the fstab.h File The fstab.
The following definitions are not available and will have an impact on your ability to port source code: • TIOCCAR • TIOCNAR • TIOCWONLINE DIGITAL UNIX systems use POSIX library routines to provide greater application portability. See Appendix D for examples of ULTRIX and DIGITAL UNIX modem control applications. B.9 Changes in the langinfo.h File The langinfo.h header file defines constants that you use to get internationalization information with the nl_langinfo routine.
Table B–1: Differences in System Limits (cont.
On DIGITAL UNIX systems, the two members of the rlimit structure, rlim_cur and rlim_max are defined as unsigned long instead of as int on ULTRIX systems. You must modify your application if it depends on this structure. Otherwise, the getrlimit and setrlimit calls will fail because of a register sign extension. B.13 Changes in the stddef.h File On ULTRIX systems, the wchar_t variable that is defined in stddef.h is declared to be an unsigned integer (32 bits).
The definition for the openlog routine is different on DIGITAL UNIX systems. On a DIGITAL UNIX system, the definition is as follows: int openlog (const char *, int, int); This definition adds an extra parameter to the openlog call. For information about using the DIGITAL UNIX openlog call, see openlog(3). B.17 Changes in the termio.h and termios.h Files The termio.h and termios.h header files define structures and flags used to control terminals.
termios Member ULTRIX Name DIGITAL UNIX Name Bit fields defined by c_oflag for system None treatment of output None PTILDE PFLUSHO PLITOUT PNL2 OXTABS ONOEOT None None None None Bit fields defined by c_lflag for control None of various terminal functions None None None None None None None PRAW PPRTERA PCRTBS PCRTERA PCRTKIL ECHOKE ECHOPRT ALTWERASE MDMBUF FLUSHO NOHANG PENDIN NOKERNINFO None None None None None B.
Table B–2: ULTRIX Header Files Not Present on DIGITAL UNIX Systems (cont.) Header File Description des.h krb.h These files define symbols used by the Kerberos library routines, which are unavailable on DIGITAL UNIX systems. You must remove references to these files and to any Kerberos routines. dial.h Contains definitions used by the dial() and undial() routines. elcsd.h elwindow.h These files define symbols used by the ULTRIX error logger routines. They are not used by user applications. execargs.
C Differences Between DIGITAL UNIX and ULTRIX System Calls This appendix describes the differences between DIGITAL UNIX system calls and ULTRIX system calls. To use the table in this appendix, look for the name of an ULTRIX system call in the left-hand column of the table. Read the second column of the table to determine what difference exists between the DIGITAL UNIX and ULTRIX system call. Read the right-hand column to determine how to get the effect of the ULTRIX system call on a DIGITAL UNIX system.
D Differences Between DIGITAL UNIX and ULTRIX Terminal Modem Control This appendix contains three sample programs showing terminal (tty) modem control: an ULTRIX program showing an outgoing phone call, a DIGITAL UNIX program showing an outgoing phone call, and a DIGITAL UNIX program showing an incoming phone call. The ULTRIX system uses TIOCCAR, TIOCNAR, and TIOCWONLINE requests to the ioctl() system call. These requests are not supported on a DIGITAL UNIX system. See Section 7.8 for more information.
Example D–2 demonstrates how a DIGITAL UNIX application interacts with a modem for outgoing calls. Error checking of the return values of the system calls is purposely omitted to simplify the example. Example D–2: Modem Control for Outgoing Calls (DIGITAL UNIX) int fd, flags; struct termios tty_termios; 1 fd = open(ttyname,O_RDWR | O_NONBLOCK); 2 tcgetattr(fd,&tty_termios); 3 if ((tty_termios.c_cflag & CLOCAL) == 0) { tty_termios.
9 10 This read() call blocks, pending the appearance of modem signals. Turns off timer; the connection with the remote system has been established. Example D–3 demonstrates how a DIGITAL UNIX application interacts with a modem for incoming calls. Error checking of the return values of the system calls is purposely omitted to simplify the example.
9 Clears baud rate bits and sets them to 2400. 10 Sets the line attributes. 11 This write call, containing the login message, blocks until someone dials in on the modem and all the signals are present. 12 Gets the user’s login name. 13 Executes the login program, if the login name is valid.
E Summary of XUI and Motif Differences This appendix summarizes the differences between the XUI and Motif interfaces in the following areas: • Terminology • Windows and window managers • Menus and menu items • Mouse button bindings • Standard message boxes • Keyboard behavior Appendix F contains a list of widget naming differences. E.1 Terminology Table E–1 lists terminology differences between the XUI and Motif interfaces.
Table E–1: Terminology Differences Between XUI and Motif Interfaces (cont.) XUI Interface Motif Interface Maximum sliders, minimum sliders Sliders (no distinction) No equivalent Maximize No equivalent Stepper buttons No equivalent Sash (window sash) Option box Option menu Pointer speed Gain Push to back Lower Quit (menu item) Exit (menu item).
Table E–2: Differences Between XUI and Motif Windows and Window Managers XUI Interface Motif Interface Does not have a root menu. Has a root menu (a menu that pops up in the root window when you press the Select button in a blank area of the root window). Shrink-to-icon button is in upper left. Shrink-to-icon (minimize) button is the left-hand button of the two buttons in the upper right. Does not have a window menu.
Table E–3: Motif Window Menu Items and Functions (cont.) Function XUI Action or Object Motif Menu Item Send a window to the back or bottom of the window stack. Push-to-back button Lower Close a window and remove it from the workspace. Not in XUI Close E.3.1 Menu Bar and Standard Menus Table E–4 lists the standard menus in each menu bar, and describes the differences between the XUI and Motif interfaces. The XUI interface uses dotted lines as separators; the Motif interface uses solid lines.
E.3.2 File Menu Items Table E–5 lists the File menu items and describes the differences between the XUI and Motif interfaces. Table E–5: Differences Between the XUI and Motif File Menu Items Menu Item XUI Interface Motif Interface New Creates an empty copy of window; does not affect the previous window. Clears the existing window; does not provide a new window. To continue to have the XUI “new” capability, include a check button in your File Selection box labeled “Open in New Window.” Open . . .
Table E–5: Differences Between the XUI and Motif File Menu Items (cont.) Menu Item XUI Interface Motif Interface Close Closes the window, leaving the Removes the primary and other windows in the application. associated secondary windows from the workspace, in applications that have more than one primary window. Closing the last primary window of an application causes the application to exit. If data will be lost, the application must prompt users to save changes.
Table E–6: Differences Between XUI and Motif Edit Menu Items (cont.) Menu Item XUI Interface Motif Interface Delete Not in XUI. Removes selected portion of data from application and compresses the rest of the data to fill the space that the deleted data occupied. Select All Selects all the data in the file. Not in Motif, but you can add it if appropriate. E.3.4 Help Menu Items The XUI and Motif Help Menu Items are shown in Table E–7.
Table E–8: Differences in the XUI and Motif Mouse Buttons Mouse Button XUI Interface Motif Interface MB1 Used for selection. Used for selection. Called the Select button. MB2 Used to display pop-up menus. Used for direct manipulation of objects and other application-specific needs. Called the Menu button. MB3 Used for application-specific needs, and for Copy To and Copy From operations, if your application supports them. Used to display pop-up menus. Called the Custom button. E.
F DECwindows Motif Component Names This appendix summarizes name changes for the following DECwindows Motif components: • Widget classes • Function names • Resource names • Enumeration literal names • Callback reason names • Compound string names • Fontlist names • Clipboard names • Resource manager names For complete descriptions of the widget classes, see the OSF/Motif Programmer’s Reference. F.
Table F–1: Widget Class Name Changes (cont.) XUI Interface Motif Interface Dwtlabel XmLabel DwtListBox XmList DwtMainWindow XmMainWindow DwtMenu XmRowColumn DwtMessageBox XmMessageBox DwtPullDownMenuEntry XmCascadeButton DwtPushButton XmPushButton DwtScale XmScale DwtScrollBar XmScrollBar DwtScrollWindow XmScrolledWindow DwtSelection XmSelectionBox DwtSeparator XmSeparator DwtSText XmText DwtToggleButton XmToggleButton DwtWindow XmDrawingArea F.
Table F–2: Function Name Changes (cont.
Table F–2: Function Name Changes (cont.) XUI Interface Motif Interface DwtSeparatorCreate XmCreateSeparator DwtSeparatorGadgetCreate XmCreateSeparatorGadget DwtSTextCreate XmCreateText DwtToggleButtonCreate XmCreateToggleButton DwtToggleButtonGadgetCreate XmCreateToggleButtonGadget DwtWindowCreate XmCreateDrawingArea DwtWorkBoxCreate XmCreateWorkingDialogb aMost of the name changes follow this form. The table lists those function name changes that do not follow this form.
Table F–3: Resource Name Changes (cont.
Table F–3: Resource Name Changes (cont.
Table F–3: Resource Name Changes (cont.
Table F–4: Enumeration Literal Name Changes (cont.
Table F–5: Callback Reason Names XUI Interface Motif Interface DwtCR AaaaAaaa XmCR_ AAAA_AAAAa DwtCRActivate XmCR_OK (XmSelectionBox) DwtCRActivate XmCR_CASCADING (XmCascadeButton) DwtCRExtend XmCR_EXTENDED_SELECTION DwtCRHelpRequested XmCR_HELP DwtCRLostFocus XmCR_LOSING_FOCUS DwtCRPageDec XmCR_PAGE_DECREMENT DwtCRPageInc XmCR_PAGE_INCREMENT DwtCRSingle XmCR_SINGLE_SELECT DwtCRSingleConfirm XmCR_DEFAULT_ACTION DwtCRUnitDec XmCR_DECREMENT DwtCRUnitInc XmCR_INCREMENT DwtCRValueChang
Table F–6: Compound String Names (cont.) XUI Interface Motif Interface DwtCStrcpy XmStringCopy DwtCStrlen XmStringLength DwtCStrncat XmStringNConcat DwtCStrncpy XmStringNCopy DwtDisplayCSMessage No equivalent in Motif. DwtDisplayVMSMessage No equivalent in Motif. DwtGetNextSegment XmStringGetNextSegment DwtInitGetSegment XmStringInitContext DwtLatin1String XmStringCreateSimplea DwtString XmStringSegmentCreatea aSuggested replacement only. F.
Table F–8: Clipboard Names (cont.
Table F–9: Resource Manager Names (cont.) XUI Interface Motif Interface DwtDrmRCSize No equivalent in Motif. Use MrmFetchLiteral, MrmFetchIconLiteral, or MrmFetchColorLiteral. DwtDrmRCType No equivalent in Motif. Use MrmFetchLiteral, MrmFetchIconLiteral, or MrmFetchColorLiteral.
G Migration from ULTRIX Version 4.5 to DIGITAL UNIX Version 4.0B This appendix contains brief descriptions of features that are new to the ULTRIX and UWS Version 4.5 operating system, and features that are new to the DIGITAL UNIX Version 4.0B operating system. Each description notes any migration issues between ULTRIX Version 4.5 and DIGITAL UNIX Version 4.0B. Then, this appendix discusses the interfaces that have been retired in DIGITAL UNIX Version 4.
• The LinkWorks components have been retired and renamed DEClinks. The retirement of the LinkWorks components have no affect on migration from ULTRIX to DIGITAL UNIX. G.2 New Features and Changes in DIGITAL UNIX Version 4.0B The remainder of this appendix contains the new and changed features in DIGITAL UNIX Version 4.0B. The discussion of each new feature and change concludes with a summary of its affect on the migration of ULTRIX Version 4.5 capabilities to DIGITAL UNIX Version 4.0. G.
folders before converting them. Do not use the -d option with this version of the mailcv utility. • dxcaltodtcm calendar conversion. This utility converts a DECwindows Calendar, dxcalendar, database for use with CDE Calendar, dtcm. G.3.1 CDE Video Tour A brief multimedia tutorial of CDE is located on the DIGITAL UNIX Version 4.0B Associated Products Volume 1 CD−ROM.
• BSD Curses G.4.1 ULTRIX Migration Issues Because X/Open Compliant Curses, Issue 4, is backward compatible with earlier versions of X/Open Curses, there are no ULTRIX migration issues. G.5 X11R6 This release of DIGITAL UNIX supports Release 6 of the X Window System, Version 11 (X11R6) patchlevel 12. Prior versions of the operating system supported Release 5 (X11R5) patchlevel 26. The DIGITAL UNIX port of X11R6 supports all the features and functionality of previous releases of DIGITAL UNIX.
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.0B. These applications include Xdec, xkbcomp, xkbprint, xkbdfltmap, dxkbledpanel, dxkeyboard, and accessx. See the reference pages for more information.
configured at run time using the -oG option on the command line. See sendmail.cf(4) for more information. G.6.2.1 ULTRIX Migration Issues There are no ULTRIX migration issues. G.6.3 df Supports Large File Systems The field width for the Iused and Ifree fields in the output of the df command has been increased to accommodate 12 digits when using the -i switch.
• infocmp−Uncompiles and, if required, compares terminfo entries. The tput and tic utilities have also been enhanced. G.6.5.1 ULTRIX Migration Issues There are no ULTRIX migration issues. G.6.6 GNU Emacs Version 19.28 GNU Emacs has been updated to Version 19.28. This version is not upwardly compatible with GNU Emacs Version 18.5, the previous version shipped with DIGITAL UNIX. See the appropriate GNU Emacs documentation in /usr/lib/emacs/etc. G.6.6.
OSFBINCOM410 and no other subsets are needed. OSFBINCOM410 is the Kernel Header and Common Files (Kernel Build Environment) subset. 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 btcreate(8) and btextract(8). G.6.8.1 ULTRIX Migration Issues Bootable tape capabilities do not exist on ULTRIX operating systems: there are no ULTRIX migration issues. G.6.
G.6.10 scsimgr Utility for Creating Device Special Files The scsimgr utility creates device special files for newly attached disk and tape devices. This utility is automatically invoked at system boot time. You can execute the command to add device special files for all disk and tape devices attached to a specified SCSI bus at any time. See the scsimgr(8) reference page for further details. G.6.10.1 ULTRIX Migration Issues There are no ULTRIX migration issues. G.
G.8 Development Environment DIGITAL UNIX Version 4.0B includes the enhancements to the development environment that are discussed in the following sections. G.8.1 Tcl/Tk Availability Tcl/Tk is now available as part of the base operating system. Tcl/Tk is a public domain unencumbered scripting language and graphical tool kit. In addition to Tcl/Tk, a popular extension package, TclX is also included. TclX provides many UNIX extensions to the Tcl command language. Tcl version 7.4, Tk version 4.
• Iostream assignment operators. 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. • String extraction operator. The String extraction operator now takes care of dynamically allocating the String to accommodate the input. • ios::ate mode.
subset, and all of the pieces outside the SDE have been moved into logical subsets, including: • OSFINCLUDE for all include files • OSFLIBA for all static libraries • OSFPGMR for commands outside the scope of the SDE 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.
G.8.5 PC-Sample Mode of prof Command The prof command’s pc-sampling mode now supports profiling the shared libraries used by a program. Linking a call-shared program with the cc command’s -p switch causes the resulting program to profile both the call-shared executable file and all the shared libraries.
G.8.6.1 ULTRIX Migration Issues There are no ULTRIX migration issues. G.8.7 Thread Independent Services Interface DIGITAL UNIX Version 4.0B 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.
G.8.9 POSIX 1003.1b Realtime Signals Realtime signals have been implemented to conform to the POSIX 1003.1b standard. This new feature includes queued signals with optional data delivery, and 16 user-definable realtime signals. The following functions to support realtime signals were implemented: • sigqueue • sigtimedwait • sigwaitinfo • timer_getoverrun G.8.9.1 ULTRIX Migration Issues There are no ULTRIX migration issues. G.8.10 POSIX 1003.
part of an obsolete draft standard and is supported in this release for compatibility only. When possible, existing applications that 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.
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 files 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.
G.9.3.1 ULTRIX Migration Issues There are no ULTRIX migration issues. G.9.4 Extensible Simple Network Management Protocol A new Simple Network Management Protocol (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 management information bases (MIBs) on DIGITAL UNIX systems.
• User profiles and ttys information are stored in database files for faster access and update (resulting in faster logins). • The new utilities edauth and convuser are available. See the Security manual and setrlimit(2), edauth(8), and convuser(8). G.10.1 ULTRIX Migration Issues ULTRIX has had enhanced security since 1990; now DIGITAL UNIX has it. Differences that affect migration are discussed in the Security manual, in an appendix on migration. G.
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. G.11.1.
– The maximum number of disks that can be added to LSM has increased from 128 to 256. – The maximum size of an LSM volume has increased from 128 GB to 512 GB. The functionality and syntax of the LSM commands used for encapsulation, unencapsulation, and mirroring have changed in this release, as follows: • • • The volencap command now supports the following features and functions. For details, see volencap(8). – Allows the initialization of LSM and encapsulation of the system disk in one step.
– The volume must map directly to the partition (that is, the volume size must be equivalent to the partition size). – The volume must not be mirrored. For details, see volunroot(8). G.11.3.1 ULTRIX Migration Issues There are no ULTRIX migration issues. G.11.4 Overlap Partition Checking Two new functions, check_usage and set_usage, 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.
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, see fold_string_w(3). For more information on the Unicode support, see Unicode(5). G.12.3 The Worldwide Mail Handler No Longer Exists Worldwide support subsets no longer install internationalized Mail Handler (MH) software in the /usr/I18N/bin/mh directory. In DIGITAL UNIX Version 4.
G.12.5 Support for Catalan, Lithuanian, and Slovene DIGITAL UNIX Version 4.0B includes support for Catalan, Lithuanian, and Slovene program localization. See Catalan(5), Lithuanian(5), and Slovene(5) for information about associated codesets, locales, keyboards, and fonts. G.12.6 man Command Supports Codeset Conversion The man command can automatically invoke the iconv utility to perform codeset conversion of reference page files.
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.
• Ethernet trailer encapsulation There are no ULTRIX migration issues. • Linkworks run-time library There are no ULTRIX migration issues. • Logical Volume Manager There are no ULTRIX migration issues. • Obsolete POSIX real-time interfaces There are no ULTRIX migration issues. • XIE V3.0 interface, server support (although run-time support will still be provided transparently through the client) There are no ULTRIX migration issues. • The POLYCENTER Common Agent (extensions to the SNMP V1.
Index A acct.h header file, B–1 ACL, G–20 acucap file, 4–3 addgroup command, 4–2 Address Resolution Protocol table command for modifying, 4–19 adduser command, 4–2 addvol command, G–8 AdvFS directory truncation, G–19 tuning, G–19 aliases database, 4–24 ANSI C, 6–16 ANSI X3.
porting shell scripts , 3–5 C shell, and migration to DIGITAL UNIX, 2–7 calculator, G–2 Calculator program, 2–3 calendar, G–2 Calendar program, 2–3 callback reason differences between the XUI and Motif interfaces, F–8 calloc function, 7–20 CAM driver interface, 7–45 captoinfo, G–6 Cardfiler program, 2–4 Catalan, G–24 catclose function, 6–21 catgets function, 6–21, 7–43 catopen function, 6–21, 7–43 cc command, 6–6 comparison of DIGITAL UNIX and DEC C compilers, 7–28 comparison of DIGITAL UNIX and ULTRIX RISC
Data Link Interface ( See DLI ) data representations, 6–2 data segment effects of -taso option, 7–10 date command, 2–5 dbx command, 6–8 dc command, 2–3 DEC C++ clog(), G–11 divide-by-zero, G–10 exception handling, G–11 ios::ate mode, G–11 "iostream assignment ops", G–10 string extraction, G–11 structured exceptions, G–11 threadsafe, G–10 underflow errors, G–10, G–11 DEC FUSE product, 6–8 DEC RPC, 1–9, 6–18 DECmigrate product migrating executables, 1–11 DECnet software, 4–18 DECterm software, 2–4 DECwindows
editing, G–2 editmode environment variable, 3–1 editor ( See specific editor commands ) elcsd daemon, 4–16 elcsd.conf file, 4–16 Emacs, G–7 encapsulation, G–21 enhanced security, G–18 _ _STDC_ _ symbol how defined, 7–21 enumeration literal differences between the XUI and Motif interfaces, F–7 environment variables codesets unavailable on DIGITAL UNIX systems, 3–3 environment variables, and migration to DIGITAL UNIX, 3–1, 6–21 errno.
fstab file format, 4–12 fstab.
ioctl system call header file, B–3 ISO/IEC 9899:1990(E), 6–16 ISO/IEC 9945-1:1990(E), 6–16 ISO9996, G–4 Iused field, G–6 K Kerberos, 1–9, 4–23, 6–18 ( See also libacl library ) ( See also libdes library ) ( See also libknet library ) ( See also libkrb library ) kernel ( See operating system kernel ) key mappings, E–8 kits utility, 6–12 Korn shell, 2–7 Korn shell DIGITAL UNIX migration to DIGITAL UNIX, 2–8 ksh shell ( See Korn shell ) L LAN, 4–18 LANG environment variable, 5–10, 6–22 setting on the command
lint command, 6–10 Lithuanian, G–24 LN01 laser printer, 4–6 local area network ( See LAN ) Local Area Transport ( See LAT ) locale database storing in the /etc directory, 5–9 locale name format, 3–3 locale, unavailable DEC Multinational, 3–3 ULTRIX ISO 646, 3–3 log files for the event-logging system, 4–16 logical storage manager ( See LSM ) Logical Storage Manager software ( See LSM software ) Logical Storage Manager subsystem "LSM", 4–17 Logical Volume Manager software ( See LVM software ) .
Message box, E–8 message catalog storing in the /etc directory, 5–9 Message Handler Utility, 2–5 mfree routine, 7–39t mh command, 2–5 MIB, 4–21 ( See Host Resources MIB ) migration to DIGITAL UNIX DIGITAL UNIX features, 1–1 executables and DECmigrate product, 1–11 features common with ULTRIX, 1–5 features not on ULTRIX systems, 1–1 ULTRIX SMP applications, 1–8 user envrionment, 2–1 mirroring, G–21 mkfdmn command, G–8 mmap system call use with taso, 7–11 modem control, 7–44 monitor, G–13 Motif interface ( Se
NFS, 4–13 NFS protocol versions, 4–13 NFS Version 2 protocol, 4–13 NFS Version 3 protocol, 4–13 nfsd daemon, 4–15 nfsiod daemon, 4–15 nfssetup command, 4–2, 4–14 nfsstat command, 4–14 nice routine, 7–39t NIS, 4–24, 6–19 nissetup command, 4–2, 4–24 NL_LANGMAX constant, B–4 NL_MSGMAX constant, B–4 NL_NMAX constant, B–4 NL_SETMAX constant, B–4 NL_TEXTMAX constant, B–4 nm command, 6–10 nonexistent header files, B–8 Notepad program, 2–5 nroff command, 2–7 nslookup command, 4–24 nsquery command, 4–24 NTP, 4–25 nt
_POSIX_C_SOURCE, G–15 PPP, G–17 preprocessor symbol predefined, 7–21 print filters list of supported, 4–7 print services, 4–6 print services, and migration to DIGITAL UNIX, 4–6 print system spooling directory for, 4–6 printcap file, 4–6 printf function, 7–19 printing, G–2 PrintServer for ULTRIX software, 4–6 prof command, 6–10, G–13 .
sed command, 2–4 select call, 7–45 sendmail utility, 4–26, G–5 services database, 4–24 services file, 4–4 session, G–2 set command, 3–5 setjmp buffer, 7–30, 7–32 setjmp routine, 7–40t setld command, 6–11 setlocale function, 6–22 setpgid system call, 7–42 setpgrp routine, 7–40t setpgrp system call, 7–42 setsockopt system call, C–1 setsysinfo system call, 7–42 setup scripts, and migration to DIGITAL UNIX, 4–2 sh shell ( See Bourne shell ) sh5 shell ( See Bourne shell ) shadowed disk migrating ULTRIX shadowed
strmerge command, 6–20 structure alignment, 7–14 structure member alignment, 7–14 structures size changes, 7–13 Style help push button, E–8 svc.conf file, 4–23 svcorder file, 4–3 svcsetup command, 4–2, 4–23 swapon command, G–8 symbol how resolved for a shared library, 8–2 Symmetric Multiprocessing software ( See SMP ) syslog.conf file, 4–16 syslog.
umount routine, 7–40t unaligned access, 7–42 Unicode, G–22 unions size changes, 7–13 UNIX File System ( See UFS ) unlink routine, 7–40t User Interface Language compiler ( See UIL compiler ) /usr/bin directory contents, 4–11 /usr/lib/so_locations file ( See so_locations file ) /usr/sbin directory contents, 4–11 /usr/ucb directory, 4–11 uucp command, 2–7 uucp utility, 4–27 uucpsetup command, 4–2 V valloc routine, 7–39t /var/adm log file, 4–2 /var/adm/smlogs directory, 4–2 variable definitions, 7–16 variables
Yellow Pages ( See NIS ) YP, 6–19 ( See NIS ) ypbind daemon, 4–24 ypcat command, 4–25 ypmatch command, 4–25 yppasswd command, 4–25 Index–14 yppasswdd daemon, 4–24 yppush command, 4–25 ypserv daemon, 4–24 ypsetup command ( See nissetup command ) ypwhich command, 4–25 ypxfr command, 4–24
How to Order Additional Documentation Technical Support If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825) before placing your electronic, telephone, or direct mail order. Electronic Orders To place an order at the Electronic Store, dial 800-234-1998 using a modem from anywhere in the USA, Canada, or Puerto Rico. If you need assistance using the Electronic Store, call 800-DIGITAL (800-344-4825).
Reader’s Comments DIGITAL UNIX ULTRIX to DIGITAL UNIX Migration AA-PS3EE-TE Digital welcomes your comments and suggestions on this manual. Your input will help us to write documentation that meets your needs. Please send your suggestions using one of the following methods: • This postage-paid form • Internet electronic mail: readers_comment@zk3.dec.
