Archive-name: dec-faq/Digital-UNIX
Posting-Frequency: monthly
Last-modified: February 12, 1997
Archive-name: dec-faq/Digital-UNIX
Posting-Frequency: monthly
Last-modified: February 12, 1997
This is the Frequently Asked Questions (and their answers) about the Digital UNIX (formerly DEC OSF/1 AXP) operating system from Digital Equipment Corporation.
This FAQ is archived in the following locations:
The archive name for this FAQ is dec-faq/Digital-UNIX
This is the Frequently Asked Questions (FAQ) collection for the Digital UNIX (formerly DEC OSF/1 AXP) operating system and, to some degrees, the systems on wich it runs. Some information relevant to the RISC ULTRIX operating systems (for the DECstation systems based on MIPS pro cessor chips) can also be found here, though there is a separate FAQ specifically for RISC ULTRIX.
A separate FAQ describes how to get information about Digital products and interacting with Digital.
To make suggestions for changes or additions to this Frequently Asked Questions list, send mail to lionel@quark.enet.dec.com. Answers are especially appreciated.
The term "Alpha" generally refers to systems based on Digital's Alpha processor.
Unless otherwise specified, these answers refer to Digital UNIX V3.2c, which is the current release. "Digital UNIX" is used even for earlier versions which call themselves DEC OSF/1.
World-Wide Web Universal Resource Locator (URL) notation is used for FTP addresses.
Many people have contributed to this list, directly or indirectly. In some cases, an answer has been adapted from one or more postings on the comp.unix.ultrix or comp.unix.osf.osf1 newsgroups. Our thanks to all of those who post answers. The name (or names) at the end of an entry indicate that the information was taken from postings by those individuals; the text may have been edited for this FAQ. These citations are only given to acknowledge the contribution.
Although the editor of this FAQ is an employee of Digital Equipment Corporation, this posting is not an official statement from Digital Equipment Corporation.
AlphaGeneration, AlphaServer, AlphaStation, Alpha AXP, AXP, DEC, DECstation, DECsystem, OpenVMS, ULTRIX, VAX and VMS are trademarks of Digital Equipment Corporation. OSF/1 is a registered trademark of the Open Software Foundation. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd. Other names are properties of their respective owners.
A list of free software known to be ported to Digital UNIX is available on the World-Wide Web:
http://www.digital.com/info/software.html
A two-CD Freeware set shipped with Digital UNIX V4.0. For an online copy, as well as reference to other freeware sources, see:
http://www.unix.digital.com/demos/index.html
Digital actively maintains an "Alpha Applications Catalog" which lists commercial software products available for Alpha systems.
http://www.unix.digital.com/catalog/index.html
Nothing. It is part of the trademark. Digital is eliminating the use of "AXP" in new product names.
Both a binary and sources for GNU Emacs are included on the base system CD-ROM. Epoch is available on the Digital UNIX Freeware CD-ROM (see answer A1 for more information).
Patches to make Emacs version 19.22 run on Digital UNIX can be found at ftp://ftp.digital.com/pub/GNU. The files are
emacs-19.22-alpha-patch.README
emacs-19.22-alpha-patch.gz
but the current version of GNU emacs (any version at least as recent
as 19.28) is said to build and run properly on Digital UNIX).
[Pete Kaiser, kaiser@acm.org]
[Rob McCool, robm@snail.ncsa.uiuc.edu]
Emacs 19.28 does NOT come with support for the DEC alpha, but the patches
for it are available from ftp://ftp.digital.com/pub/GNU.
So you have to get emacs-19.28 and then the patch as well. Once you get
the patch, it builds flawlessly. (Well, at least it did for me.) The documentation
within emacs 19.28 says that hopefully in 19.29 Alpha support will be built
into the standard emacs distribution.
[holt@cns.caltech.edu]
Sites, R.L., Ed., Alpha Architecture Reference Manual (600 page book, 1992) from Digital Press (EY-L520E-DP) or Prentice-Hall 9ISBN 0-13-033663-7). Also at most technical bookstores, including Quantum(Cambridge) and Stacey's (Palo Alto)
Communications of the ACM, February 1993 issue (4 Alpha articles)
Digital Technical Journal, Vol 4., No. 4 (200 pages of Alpha articles, including 4 above with fewer typos). Order info: dtj@crl.dec.com (Available from ftp://ftp.digital.com/pub/DEC/DECinfo/DTJ and http://www.digital.com/info/DTJ/dtj.html)
Jim Montanaro "The Design of the Alpha 21064 CPU Chip" (42
minutes) Dick Sites and Dirk Meyer, "Alpha Architecture" (73
minutes) University Video Communications P.O. BOx 5129 Stanford CA 94309
USA (415) 813-0506
[Dick Sites, sites@tallis.enet.dec.com]
As of November 1, 1995, Digital's service of Internet-accessible Alpha "test drive" systems was suspended. A revised service may appear in the future. For more information, write to Jack Lucier at lucier@kacie.enet.dec.com.
We are happy to announce the creation of an unrestricted FTP and WWW area for Alphaservers. This area is accessible to both internal and external folks. The information includes firmware updates, the latest configuration utilities, software patches, a list of supported options, hardware documentation, and more. The area is under construction, so not everything is in place yet.
The files available for FTP are located at:
ftp://ftp.digital.com/pub/Digital/Alpha/
The WWW pages are located at:
http://www.service.digital.com/alpha/server/
We hope that these pages will be useful. Please send your comments and
feedback to alpha_server@service.digital.com
syd, a utility like top, is on the Freeware disk for versions of Digital UNIX before V3.0. It is also available for anonymous FTP from many sites. One is ftp://ftp.Uni-Koeln.DE/decosf and there you can also get a version that works with version 3.x of Digital UNIX.
The latest official version of top (3.3) supports single cpu Alphas running OSF/1 1.2, 1.3, 2.0, 3.0, and 3.2. It's at ftp://eecs.nwu.edu/pub/top It does not support multi-cpu alphas, because no-one with root access to a multi-cpu alpha has stepped forward to do the work. When compiling, note the warning about compiling with optimisation.
lsof, a utility for listing open files, is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof.
vmubc is a graphical and tty-based tool for displaying statistics on
CPU, UBC, and virtual memory. Note that to compile on OSF/1 2.x, add -DGSI_CPUS_IN_BOX=55
to the CFLAGS. vmubc is available from
ftp://gatekeeper.dec.com/pub/Digital/vmubc.tar.Z. It was written by
George Chaltas of DEC.
[Dave Sill, de5@ornl.gov]
[Anthony Baxter, anthony@aaii.oz.au]
Try
setenv MXR_TRACE_SYSCALLS open,stat,fstat,access
Running mxr -help will describe this environment variable along with
some other useful ones.
[Richard Gorton, gorton@blorf.amt.ako.dec.com]
The previewer psview is available from
http://www.ensmp.fr/~bourdonc
[Francois Bourdoncle, bourdoncle@pa.dec.com]
The current version of tcsh is 6.07. Look for it at:
ftp://ftp.primate.wisc.edu/pub/csh-tcsh-book
or
There are a few options for playing audio on Alpha systems. Most workstations come with 8-kHz mono audio I/O hardware that is enabled by configuring the bba (base board audio) device in the kernel. The Sound & Motion J300 a/v TURBOchannel option card also has audio hardware that support programmable sample rates from 8kHz to 48kHz stereo.
Two software packages are available to drive audio on Alpha systems:
MME implements a Microsoft-style API and comes bundled with OSF/1.
AF, developed at Digital's Cambridge Research Laboratory runs on a wide range of platforms including DECstation, Alpha, Sun, SGI, and HP. It is available in source form from
ftp://ftp.digital.com/pub/DEC/AF
[Lance Berc, berc@src.dec.com]
Sources for xcd are included in /usr/examples/motif/xcd. Another version of xcd is on the Freeware CD-ROM in both source and binary form, but that version may have been superseded by the one distributed with the operating system. Neither cdp nor xcd is supported by Digital.
Two other programs are Workman and xmcd, both of which can be found
on ftp.x.org. Of all these programs, xmcd seems to be the widest used and
to have the largest database of audio CD data.
[Anthony Baxter, anthony@aaii.oz.au]
[Peter Kaiser, kaiser@acm.org]
DECmigrate for Digital UNIX Systems was announced with all of the Alpha AXP systems on November 10, 1992. For more information, look at the announcement article for the UNIX community:
ftp://ftp.digital.com/pub/DEC/DECinfo/DECnews-UNIX/0117.txt
and the DECmigrate for Digital UNIX Software Product Description (SPD):
ftp://ftp.digital.com/pub/DEC/DECinfo/SPD/39-45-01.txt
[Russ Jones, rjones@pa.dec.com]
The Digital Porting Assistant (available for Digital UNIX 3.2, and shipped as part of the developer's toolkit on Digital UNIX 4.0) is a graphical environment which aids in the porting process. In addition to doing lint-like checking of C and Fortran code, it also contains extensive on-line help regarding developing software on Digital UNIX. Information about the Digital Porting Assistant can be found on the web at: http://www.digital.com/info/porting_assistant
The version of lint shipped with Digital UNIX has many checks to help port software to Alpha. In particular, the -Q option is very useful. See the manual page for more details.
There is also a document/book entitled: Interoperability, OpenVMS and DEC OSF/1 Interoperability Guide. EC-N3399-43.
A company called Sector 7 deals with porting software from OpenVMS to Digital UNIX : http://www.sector7.com.
A document entitled "SunOS to DEC OSF/1 Porting Guide" is available from ftp://ftp.digital.com/pub/DEC/DECinfo/document/EC-N0736-43.ps.Z
The -taso flag to cc will often help with making code work on the 64bit Alpha. This causes addresses to be 32-bits and should be used only as a last resort.
FreePort Express is a binary translator (running on Alpha) which permits you to convert your SunOS 4.1.x (same as Solaris 1.x) user executables into Digital UNIX executables in minutes. FreePort Express runs under Digital UNIX V3.0 or later, and is available FREE of charge (hence the name). http://fenris.novalink.com/freeport-express/
The development environment is a separate layered product beyond the base OS. Although it is included on the Digital UNIX consolidated CD-ROM, the license must be purchased separately to use any portion of the Developer's kit. Within the Digital UNIX Developer's Kit the license just happens to be enforced by a check in dbx.
For more information, look in ftp://ftp.digital.com/pub/DEC/DECinfo/DECnews-UNIX for:
0104.txt Digital UNIX Developer's Extensions V1.2 article, 11/17/92
0603.txt Digital UNIX Developer's Toolkit V1.2 article, 03/23/93
0806.txt C Compiler for Digital UNIX Operating System article, 05/13/93
[Russ Jones, rjones@pa.dec.com]
Sometimes the details of the shared libraries change between releases. In general, applications compiled on an earlier version of Digital UNIX should still run on a later version. The converse may not be true.
The usual solution is to recompile from scratch.
[John Kohl, jtkohl@zk3.dec.com]
ftp://ftp.digital.com/pub/misc/malloc_dbg.
If you get the package, be sure to read the stuff in the file contrib/dec_notes
which explains how to replace malloc on the fly in an existing program.
[Dave Hill, ddhill@zk3.dec.com]
The ATOM tools with Digital UNIX 3.0 and later also help with debugging
memory allocation problems.
[Anthony Baxter, anthony.baxter@aaii.oz.au]
Sentinel, from AIB Software Corporation is a run-time analysis tool
that supports memory access error detection as well as leak detection on
Digital UNIX. More info, as well as free evaluation copies, is available
from info@aib.com, or by calling 800-296-3000 (703-787-7700).
[Conor P. Cahill, cpcahil@aib.com]
Some libraries on Digital UNIX (notably the X11 library) are compiled so that they can use DECnet as well as TCP/IP. To link with such libraries, include -ldnet_stub at the end of link command. If you have DECnet software installed, use -ldnet.
1. Use the dbx debugger.
2. Use the "file" program (e.g., file
3. Use "strings" to find clues in the core file (e.g., strings
Unaligned accesses typically come up when programs use malloc(3) or other memory allocation routines in atypical ways, or when programs do certain (hazardous) kinds of type casts.
malloc(3) returns data aligned to the most restrictive alignment (8 byte boundaries on MIPS machines). If you are writing your own malloc wrapper (say to add a reference count) and you write code like this:
char *mymalloc(int size)
{
short *newmem;
newmem = (short *) malloc(size + sizeof(short));
*newmem = 1; /* initialize reference count */
return (char *) (newmem + 1);
}
you are then returning a pointer that is no longer 8-byte aligned. Now, code like
int *i;
i = (int *) mymalloc(sizeof(int));
*i = 10;
will generate unaligned access messages whenever *i is used.
An example of dangerous casting would be something like
char buffer[100];
int i;
i = (int)*((int *)&buffer[3]);
The program will usually still run correctly, because an exception handler in the kernel performs an unaligned read. There are some rare cases, however, where the fixed read yields incorrect results. The messages are printed by default because one usually wants to know when a program is generating the unaligned accesses.
Now, if you're only getting a few of these messages, it might not matter, but if you're getting pages of them (or worse, have turned off the logger because you were getting so many unaligned access messages), you might consider correcting your program.
You can use the uac(1) (Unaligned Acces Message Control) command to turn off the messages.
If you want to find the the problem in the source code, you can use dbx. Suppose the message is:
Fixed up unaligned data access for pid 2337 (bozo) at pc 0x5ad364
This tells you that the problem occurs in the program "bozo". In dbx, you would type, for example:
% dbx bozo
(dbx) 0x5ad364/i
*[main:206, 0x0x5ad364] lw r0,40(sp)
dbx prints the offending instruction, along with its location: line 206 in main().
s is most often caused by COMMON blocks in which variables are not naturally aligned. For example:
REAL*4 X
REAL*8 Y
COMMON /CMN/ X,Y
Y will be at offset 4, which is not a multiple of its size (8). The
best solution is to rearrange variables in the COMMON so that real, complex
and integer variables are listed in order of decreasing size, followed
by CHARACTER variables. Put your declaration in an INCLUDE file to make
sure all uses are consistent! You can also ask the compiler to automatically
add padding to align variables through the -align dcommons switch, or through
a CDEC$ OPTIONS directive. See the DEC Fortran User Manual for further
details.
[Steve Lionel]
Question: how does one get microsecond resolution from the gettimeofday(2) system call?
Answer: Normally, Digital UNIX updates its internal idea of the current time once per clock tick (1024 Hz, or about once per millisecond). In Digital UNIX V4.0 and later, it is possible to rebuild the kernel to support approximately microsecond resolution from the gettimeofday(2) system call, and from the various library routines that use this system call.
To enable this option, add the following line to the kernel configuration file and rebuild the kernel:
options MICRO_TIME
The system clock (CLOCK_REALTIME) resolution as returned by clock_getres(3) will not change. Timer resolution remains the same. However, the granularity of the time returned by gettimeofday(2) and clock_gettime(3) will now be in microseconds. The time values returned are SMP safe and monotonically increasing.
The high-resolution clock can be used for timestamping and for measuring
durations on the order of microseconds, such as time spent in some critical
code path.
[Jeff Mogul]
If your application is sending lots of data (using, say, PutImage requests),
try setting DISPLAY to local:0, which uses a shared memory transport between
the client and the X server.
[Gail Grant]
XV 3.10a supports Digital UNIX. It can be obtained from: ftp://ftp.cis.upenn.edu/pub/xv xv is also included on the Freeware CD-ROM (see question A1).
Add the lines
host:0 host.sub.domain:0
to the file /etc/securettys to allow root to login.
[szabo_p@maths.su.oz.au]
If you get the error 'Cannot obtain database information on this terminal', Follow this advice from the DEC support people and change the files /etc/auth/system/ttys, /etc/auth/system/devassign and /etc/securettys as follows: In the following, replace host, host.sub.domain and n.n.n.n by the hostname, full domain name and IP address of the host(s) you are trying to connect from. Add lines like the following to /etc/auth/system/ttys :
host\:0:t_devname=host\:0:t_xdisplay:t_login_timeout#0:chkent:
Add lines like the following to /etc/auth/system/devassign :
host\:0:v_devs=host\:0,host.sub.domain\:0,n.n.n.n\:0:v_type=xdisplay:chkent:
Add lines like the following to /etc/securettys :
host.sub.domain:0 host:0
[szabo_p@maths.su.oz.au]
Digital UNIX uses the IP type-of-service option (TOS) by default. This confuses some systems (reportedly Macintoshes). To turn off the option for ftp, create a file /etc/iptos with the following entries:
ftp-control tcp 0x0
ftp-data tcp 0x0
Reboot the Alpha system.
Jon Forrest (forrest@cs.Berkeley.EDU) has written a document that describes how to do this. Look in ftp://s2k-ftp.cs.Berkeley.edu/pub/personal/forrest/remote.mounting
Note that as of OSF 1.3 DEC does not support this but it is quite easy
to do.
[Jon Forrest, forrest@postgres.Berkeley.EDU]
rstatd is in usr/sbin/rpc.rstatd.
- Shutdown the system.
- At the ">>>" prompt, type:
set ethernet thick
or
set ethernet tenbt
- Reboot the system.
[Steve Imber, stevei@anduril.fsc.qut.edu.au]
For the AlphaStation and AlphaServer systems, the syntax is different and depends on what Ethernet adapter you're using. For Digital EtherWorks adapters, they'll automatically select between AUI and 10 Base-T but you may have to use the console command:
set EWA0_MODE AUI
to have this happen.
Information about software for multicast applications on Digital UNIX is available from:
http://s2k-ftp.cs.berkeley.edu:8000/sequoia/conferencing
or
ftp://s2k-ftp.CS.Berkeley.EDU/pub/sequoia/conferencing
[Fred Templin, templin@postgres.Berkeley.EDU]
Binaries of the MBone application suite are also available at
http://chocolate.pa.dec.com/mbone
or ftp://chocolate.pa.dec.com/mbone
[Lance Berc, berc@src.dec.com]
xdr_long is used for sending signed 32-bit values and cannot send 0xFFFFFFFF.
xdr_ulong should be used instead. For 64-bit integer values, use xdr_hyper.
See the manual pages for more details.
[Curtis Keller, curtis@kinesix.com]
This is slightly misleading. xdr_long() can send -1, which in 32 bits is 0xffffffff. xdr_long() does range checking, insuring that the top 33 bits of its 64-bit argument are all ones or all zeroes. If this is not the case, then the signed long integer is beyond the range of representation within a signed 32-bit value, and xdr_long() rightly fails.
xdr_u_long() [note typo above!] insures that the top 32 bits of its 64-bit argument are all zero. If this is not the case, then the unsigned long integer is beyond ... blah blah.
So, the upshot is: If you're using signed values, use xdr_long(), and
DON'T use unsigned constants like 0xffffffff to set variables. If you're
using unsigned values, use xdr_u_long(). In both cases, make sure you're
within range for 32-bits, if you want to interoperate with 32-bit machines
using native data types.
[John Kohl,jtk@atria.com]
1) Installing packet filter support tcpdump relies on a kernel option
that ordinarily isn't enabled. You can fix this either by adding "options
PACKETFILTER" to the system's configuration file and rebuilding (via
doconfig -c
# doconfig
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
Enter a name for the kernel configuration file. [ALINGO]: FILTER
You want to name the configuration file 'FILTER'
Is that correct? (y/n) [y]: y
*** KERNEL OPTION SELECTION ***
Selection Kernel Option
---------------------------------------------------------------
1 System V Devices
2 Logical Volume Manager (LVM)
3 Kernel Breakpoint Debugger (KDEBUG)
4 Packetfilter driver (PACKETFILTER)
5 STREAMS pckt module (PCKT)
6 Data Link Bridge (DLPI V2.0 Service Class 1)
7 X/Open Transport Interface (XTISO, TIMOD, TIRDWR)
8 File on File File System (FFM)
9 ISO 9660 Compact Disc File System (CDFS)
10 Audit Subsystem
11 Local Area Transport Support
12 All of the above
13 None of the above
---------------------------------------------------------------
Enter the selection number for each kernel option you want.
For example, 1 3 : 4
You selected the following kernel options:
Packetfilter driver (PACKETFILTER)
Is that correct? (y/n) [y]:
...
Rebuild and boot the new kernel. 2) Create the packetfilter devices:
# cd /dev # ./MAKEDEV pfilt MAKEDEV: special file(s) for pfilt: pfilt0 pfilt1 pfilt2 pfilt3 pfilt4 pfilt5 pfilt6 ... pfilt63
3) Get a better tcpdump (pre V4.0 systems only) Email me for a compressed, uuencoded file of a tcpdump that decodes NFS V3 and several other Sun RPC protocols (MOUNT, NIS, NLM, PORTMAP, and STATMON). 4) Enable local copy promiscuous mode
# pfconfig +p +c ln0 (or tu0 or whatever)
5) Run tcpdump Please read the man pages before doing serious monitoring! To look at some NFS traffic, try:
# tcpdump -s300 -c100 -Nt udp port 2049 [to look at all NFS traffic] # tcpdump -s300 -c100 -Nt host foo [to look at all to/from foo]
-s300 "snaps" up the first 300 bytes of each message, generally enough to get lower level headers, RPC, and enough NFS protocol to make sense of the requests. -c100 says to capture 100 messages and exit. -N says to suppress the domain name (e.g. .zk3.dec.com) in hostnames. -t says to suppress printing timestamps. The result is usually still too long for a 80 column screen, I keep a wide xterm lying around for most of my tcpdump monitoring. The -m option splits some messages over multiple lines.
If you send people traces, I generally recommend that you capture data to a binary file and send that. If the recipient needs to, he can run tcpdump with extra filtering or -x (hex dump) to really dig into problems. Do something like:
# tcpdump -w /usr/tmp/foo.dmp -s300 udp port 2049 tcpdump: listening on ln0 Using kernel BPF filter ^C 1040 packets # compress foo.dmp # uuencode foo.dmp.Z < foo.dmp.Z > foo.uu
Capturing to a file bypasses all the decoding code which can be very
slow and can generate its own IP traffic (e.g. resolving host names).
[Ric Werme, werme@zk3.dec.com]
[Jim Gettys, jg@crl.dec.com]
Some parallel printers are supported by Digital UNIX - see the Software Product Description for a list. If you are unable to get a printer working, the following tips may be helpful. If you can do "date > /dev/lp0" successfully, then it should also work with lpd. Trouble is, lprsetup adds an "rw" tag in /etc/printcap which lets the data flow stall. You might try something like this:
# parallel connection lp3|3|fleet|post:\ :lf=/usr/adm/lpderrs:\ :lp=/dev/lp0:\ :mx#0:\ :pl#66:\ :pw#80:\ :sd=/usr/spool/lp3:\ :sh:\ :xf=/usr/lbin/xf:
BTW: That was for an HP Laserjet before we used its JetDirect (=Ethernet) card which supports lpd directly via TCP/IP. The entry for this usage is:
# ether connection lp3|3|fleet|post:\ :lf=/var/adm/lpderrs:\ :lp=:\ :rm=fleet:\ :rp=fleet:\ :sd=/var/spool/lp3:\ :mx#0:\ :sh:
The printer has an IP address of its own and is called "fleet".
I have seen for the "rp" tag names like "raw" or "text"
to distinguish between postscript or text but the above entry works as
well. Users that need to print text use "unix2dos" as filter
but we'd rather discourage that and favour dot matrix printers for that
purpose.
[Michael Sternberg, sternberg@physik.tu-chemnitz.de]
A collection of contributed printcap entries is in ftp://ftp.digital.com/pub/DEC/ultrix-printcap Get a copy of the file for an up-to-date list. Despite the name, these are good for Digital UNIX as well.
This describes the 6-pin modified modular jack (MMJ) used for serial ports on various DECstations and VAXstations, as well as on other DEC equipment.
DEC carries four DB-to-MMJ adaptors. They are internally wired as follows
Rdy Out TX+ TX- RX- RX+ Rdy In
Adaptor Gender 1 2 3 4 5 6 Use with:
--------------------------------------------------------------------------
H8575-A F 20 2 7 7 3 6&8 VTxxx terminal
H8571-C M 6 3 7 7 2 20 DEC printer
H8571-D M 6 3 7 7 2 20 Modem
H8571-E M 20 2 7 7 3 6&8 Female terminal
or LaserWriter
--------------------------------------------------------------------------
RS-232 using DB-25 connectors:
DTE DCE
Terminal Modem
or computer
Pin Number Signal Name
2 TD Transmit Data -->
3 RD Receive Data <--
7 GND Ground ---
6 DSR Data Set Ready <--
8 DCD Data Carrier Detect <--
20 DTR Data Terminal Ready -->
newfs is smart enough to get the geometry of the disk from the drive, although this feature is not documented for all versions. Use
newfs /dev/rrz#x /dev/rrz#x
to do this.
For most uses, you don't need a disktab entry on Digital UNIX. The disklabel command can get the default partition table and geometry from the disk driver and will put that in the label. When the label is present, newfs doesn't need a disktab entry either.
A collection of contributed disktab entries is in /pub/DEC/ultrix-disktabs on the usual archive machines. Get a copy of the file for an up-to-date list. The disktab collection may also be used on Digital UNIX, but not all entries have been tested on all platforms.
If you have a floppy disk drive on your ULTRIX or OSF/1 system, get "mtools", a set of MS-DOS utilities for UNIX. The package can be copied from ftp://prep.ai.mit.edu/pub/gnu/mtools-2.0.7. It works on both DECstations and Alphas.
When you build mtools, you need to find out which device your floppy
is (/dev/rrz2c is common). Then you can clone the SPARC definitions, or
#define SPARC and make /dev/rfd0c a symlink to the one you need.
[Win Treese, treese@lcs.mit.edu]
For disks that do not have entries in the /etc/disktab file, the following disklabel command will query the disk itself for geometry information:
disklabel -rw /dev/rrzXc unknown
Where /dev/rrzXc is the device name of the disk.
[John Speno, speno@swarthmore.edu]
You can join the mailing list alpha-osf-managers@ornl.gov. Send a message with
subscribe alpha-osf-managers
in the body to Majordomo@ornl.gov.
[Dave Sill, de5@ornl.gov]
Archives of alpha-osf-managers mailings are kept at:
http://www-archive.stanford.edu/lists/alpha-osf-managers/hyper/
and http://www-archive.stanford.edu/cgi-bin/fwais.pl
Some applications on OSF/1 use termcap; others use terminfo. tic(1)
compiles a termcap definition for terminfo. It is best to add a new terminal
definition both ways.
[Jeffrey Heller, jeffreyh@kpc.com]
>>> boot -fl s
-fl specifies the flags to the booted image.
[Boris Yost, boris@msc.cornell.edu]
[The following is a "position statement" on this subject from Digital]
As part of its reorganization in March of 1994, the Open Software Foundation announced transition plans for its existing technologies. It has been well understood since then that the June 1994 release of OSF/1, the OSF's operating system source code, would be the last. The possibility remains open that OSF sponsors may choose to fund additional work in the operating system area, but no projects are underway.
It is important to understand what OSF/1 is and has always been. It is not a finished operating system but a set of operating system technology components, from which vendors can pick and choose pieces of technology that complement their product development strategies. Many UNIX system vendors use elements of OSF/1 code -- Hewlett-Packard in HP-UX, IBM in AIX, and many others, including Digital in Digital UNIX.
Digital uses components of OSF/1 technology, just as it integrates technology from other suppliers with its own internal development. By following this strategy of integrating needed components, Digital has been able to produce the best implementation of the UNIX operating system in the industry and to bring it to market quickly.
Since the initial releases, development of Digital's product has not been dependent on OSF code. Digital's plans for the future development of Digital UNIX are fully under Digital's control, and our plans for a fully SPEC 1170 compliant version, UNIX clusters, and other leading commercial enhancements are on course.
There is a utility called vmsbackup to do this. Earlier URLs for this
software are now invalid - the following is part of a set of FreeBSD ports
- it may or may not work on other UNIX systems.
http://www.ee.freebsd.org/ports/emulators.html#vmsbackup-3.0
If you are having a problem dealing with Digital that you cannot satisfactorily resolve through your local Digital office, please contact US Customer Relations at:
Internet: response@mkots3.enet.dec.com
Phone: 800-DEC-INFO or 603-884-0915
FAX: 603-884-4692
Mail: US Customer Relations
Digital Equipment Corporation
Digital Drive, MKO2-2/D15
P.O. Box 9501
Merrimack, NH 03054-9501
Non-US customers may also use these contacts; information will be directed to the appropriate corporate office. Please include your name, organization, address, phone number and Internet address in all correspondence.
[Castor Fu, castor@drizzle.Stanford.EDU]
biz.digital.announce is Digital Equipment Corporation's newsgroup for posting business information on products, services, significant contracts, organizational announcements, cooperative marketing agreements, alliances, seminars, promotions, etc.
The newsgroup will be organized so that you can use a "kill" file with your newsreader to skip over (or ignore) classes of announcements that are not of interest. All postings will be organized along the following lines:
Subject: Press/... Digital Press Releases
Subject: Fact Sheet/... - Supporting Fact Sheets
Subject: Backgrounder/... - Supporting Editorial Backgrounders
Subject: Partner/... Press Releases from Digital's Partners
Subject: Seminar/... Seminars offered by Digital
Subject: Promotion/... Sales Promotions offered by Digital
Subject: Show/... Digital Tradeshow Activities
Subject: Training/... Digital Education & Training
The new biz.digital hierarchy is:
biz.digital.announce News and Announcements
biz.digital.articles Newsletters, Catalog, and Journal Articles
World-Wide Web:
http://www.digital.com/info/performance.html
FTP:
ftp://ftp.digital.com/pub/Digital/info/performance
Security problems or questions should go to your normal Customer Support Center.
Remove the file /sbin/swapdefaults and reboot.
Digital UNIX has two paging modes, lazy and conservative. Conservative
means that paging space is allocated as memory is allocated, guaranteeing
that there is always somewhere to page to. This limits VM to the size of
the paging partitions, but makes for a very robust system. Lazy is more
like what people are used to with Unix - paging space is allocated when
needed for paging out, you can run more jobs, but you're in big trouble
when everything fills up. By default, Digital UNIX comes up in the conservative
mode. Removing the swapdefaults file changes the system to lazy mode.
[Lance Berc, berc@src.dec.com]
Versions of Digital UNIX earlier than V3.0 use the /upgrade file to allow access to non-root users. Generally, on these versions, the inability of non-root users to log in is due to a problem with this file. Typically, this file gets deleted by somebody who doesn't understand its purpose. To recover from this problem, do one of the following:
1. cp -p /upgrade0 /upgrade 2. copy /upgrade from another pre-V3.0 Digitial UNIX system. 3. Obtain the O/S distribution media and extract the /upgrade0 file. a. mount -r /dev/rzc /mnt b. cat /mnt/ALPHA/BASE/OSFBASE200 | uncompress | tar xvf - ./upgrade0 c. cp upgrade0 /upgrade
NOTE: the 200 in OSFBASE200 varies based on the O/S version.
Digital UNIX V3.0 uses the OSF-BASE and OSF-USR PAKs to determine the amount of users allowed. A valid OSF-BASE PAK is required to activate the OSF-USR PAKs. By default, the OSF-BASE PAK alone provides 2 concurrent user support by activating an OSF-USR PAK which is automatically installed. If zero non-root users can login, then you probably have not installed your OSF-BASE PAK properly or it has expired. (Use the "lmf list" command to see the list of installed PAKs. A PAK is good if its status is "active".) Install a valid OSF-BASE PAK. If the problem still persists, then you likely do not have any OSF-USR PAK. Since one is automatically installed for you, this means that somebody inadvertantly deleted the PAK. You can recover this PAK by entering the following:
/sbin/it.d/bin/twouser
Two concurrent users should be allowed to login at at this time.
If your problem is that only two users are allowed to login at the
same time, then you probably need a larger or additional OSF-USR PAKs.
If you have installed an "unlimited user" OSF-USR PAK but are
seeing a restriction on the number of users allowed to login, delete all
OSF-USR PAKs other than the PAK which provides for unlimited users.
[Dave Parker, djp@unx.dec.com]
The following table correlates the output of the "uname -a" command to the "marketing name" for various Digital UNIX (DEC OSF/1) versions:
V2.0 240
V3.0 347
V3.0B 358.78
V3.2 214
V3.2A 17
V3.2B 214.61
V3.2C 148
V3.2D-1 41
V3.2D-2 41.64
V3.2F 69.73
V3.2G 62
V4.0 386
[Dave Parker, djp@unx.dec.com]
Yes - http://www.unix.digital.com/
Some users have experienced problems recovering ample disk space after an update installation has aborted due to insufficient space. The following is an example of a typical problem encountered during an update:
1) The update installation exits and indicates that additional space is needed in a particular file system (root, /usr, and/or /var) to perform the update.
2) The user deletes or moves files from the affected file system and/or removes subsets.
3) The user initiates another update attempt.
4) The update installation aborts again because of lack of space, even though the user believes that the space requested during the first attempt has been recovered.
There may be several reasons for this problem:
The proper methods for freeing disk space are as follows:
1) Remove any non-critical optional subsets using 'setld -d'. Deleting or moving individual system files without using the 'setld' command will not yield the additional space needed to continue.
Refer to the appropriate appendix of the Installation Guide containing the subset size information that corresponds to the version of Digital UNIX that you have currently installed to help you decide which subsets to remove.
2) Remove any non-critical user-added files which are not part of the base or layered product inventory. Typical large space consumers are left over core files and kernels that are no longer required.
3) For those who have previously performed Digital UNIX update installations, left over obsolete system files, .PreUPD files, and .PreMRG files can use significant amounts of file system space. Use the 'updadmin' utility to first back-up then delete these files. Refer to the installation guide for more information on using updadmin.
4) For AdvFS filesystems, it is possible to save approximately 3MB in root by building a mandatory only kernel (the default) rather than an interactive kernel (i.e. do not specify the "-i" flag to installupdate). Note that you must specify the "-i" flag if there are optional kernel selections that your system depends upon that cannot be satisfied by a mandatory kernel. Section 5.20 of the Digital UNIX 4.0 installation guide gives descriptions of each kernel option.
There is currently a known problem with the update space calculation procedure for AdvFS file systems. The bug may cause the update installation to report an amount of 'additional space needed' that is smaller than what is actually necessary. Therefore subsequent update attempts may still request additional space even after the amount originally requested has been freed. This bug will not corrupt your existing system or prevent you from performing an update, but it may cause you to have to free space and restart the update more than once.
This bug has been fixed for Digital UNIX 4.0B.
When removing small files (less than 8K) from an AdvFS file system, additional free space may not be made available to the file system immediately. After the total amount of space consumed by these deleted files reaches a threshold value, all of the space is made available in one large block. This explains why deletion of several small files may not increase the available block count (as shown by "df", for example). In this case the user must continue to delete non-system user-added files until there is an adequate increase in the available block count to allow the update installation to continue.
[Brad Musolff, bdm@unx.dec.com]
Deleting files which are part of installed base or layered product subsets will not produce additional free space because the update installation takes into account that these old files will be replaced by new versions. The disk space calculation determines how much additional space is needed to replace an old version of a file with its new version.
If the old version of a file is removed without removing the entire subset in which it resides, the update installation will still put the new version on the system. In this situation the full size of the new file will be allocated instead of the difference between the size of the original and new versions.
For example, if /genvmunix was 7MB and a new version of /genvmunix was 8MB, update would need to reserve 1MB of free space for the new version. If /genvmunix was deleted before the update, the disk space calculation would then reserve the full 8MB for the new file. So although 7MB was freed before the update, 7MB more would be reserved during the update, which would result in no difference in the amount of additional space needed to continue the update.
[Brad Musolff, bdm@unx.dec.com]
Elaborate instructions are given on a Web page titled "Digital UNIX Tuning Parameters for Web Servers", available at http://www.digital.com/info/internet/document/ias/tuning.html
This page is updated from time to time, as new information becomes available.
[End of FAQ]