This is the Frequently Asked Questions (FAQ) posting (and their answers) about the ULTRIX operating system from Digital Equipment Corporation.
This FAQ is archive in the following locations:
The archive name for this FAQ is dec-faq/ultrix
This is part 1 of the Frequently Asked Questions posting for comp.unix.ultrix, with answers about the ULTRIX operating system. It is also posted on comp.sys.dec, but it is not a full FAQ for comp.sys.dec. Companion postings have answers that apply to Digital UNIX.
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.
An archive of recent postings to comp.unix.ultrix can be found at ftp://ftp.cc.rochester.edu/pub/usenet/comp.unix.ultrix
Thanks to folks at the University of Rochester for providing this service.
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. Other names are properties of their respective owners.
DPSViewer*watchProgress: on
to make this the default behavior. Some reports indicate that this resource only works properly on ULTRIX 4.2A and later, however.
Some have reported that disabling the use of PostScript comments also helps:
DPSViewer*useComments: off
The biggest trick in compiling perl on RISC/ULTRIX is fixing its notion of "volatile". To do this, when Configure stops and asks you if you want to edit config.sh, do so. Search for the word "volatile" and change the "define" on that line to "undef". This step is reportedly not necessary for versions perl version 4.0, patchlevel 36 and later.
On machines with a relatively small amount of memory, you may not want to use -O on eval.c, since the compiler can end up taking a long time to compile that file.
If the source directory is NFS-mounted, it is usually the case that you will see the message
io/fs..........FAILED on test 18
This is harmless and can be ignored.
Another version that supports regular expressions in syslog.conf is available from ftp://decuac.dec.com/pub/DEC/syslog_mjr.tar.Z
A version integrated with Net2 code and which builds under Ultrix 4.x
is available at:
ftp://ftp.cic.net/pub/Software/unix/ultrix-net2-syslogd.tar.gz
[Paul Southworth, pauls@cic.net]
For gdb 4.0 and later:
- unpack the tar file
- cd
- ./configure +subdirs decstation
- cd H-decstation/T-decstation
- gnumake
This will build the gdb binary in
Install this binary in the location of your choice (e.g. /usr/local/bin)
DEC OSF/1 AXP does, however.
1. The 4.3BSD man program, available from
ftp://decuac.dec.com/pub/sources/bsd-man.shar.Z
2. man, from ftp://ftp.che.utexas.edu/pub/unix/man-1.1.tar.gz
Not an FSF program, but distributed under the GNU GPL.
3. Tom Christiansen's PERL man program, from:
ftp://convex.convex.com/pub/perl/scripts/man.shar.Z
(Requires perl)
4. For those with Tcl/Tk, try tkman, available from:
ftp://ftp.cs.berkeley.edu/ucb/people/phelps/tcltk/tkman.tar.Z
Alpha OSF/1 man understands MANPATH.
[Frank Wortner, frank@croton.nyo.dec.com]
[Win Treese, treese@crl.dec.com]
[Philip J. Tait, pjt@pelab.allied.com]
[Tom Phelps, phelps@ecstasy.cs.berkeley.edu]
Another vacation program, written in perl, is available from ftp://convex.convex.com/pub/perl/scripts/clones/vacation
Both of these are careful about to whom and how often they reply.
DEC OSF/1 includes the BSD vacation program.
[Win Treese, treese@crl.dec.com]
[Brian Smith, brian@magnus.acs.ohio-state.edu]
A somewhat different version of named called cra-bind that does not have this problem. This version cannot use Kerberos for server-server authentication, as the ULTRIX version can. It does support Hesiod data and queries. It is not supported by Digital, although it is in active use on Digital's Internet machines.
cra-bind has been superseded by the public release of BIND 4.9. BIND 4.9
can be obtained from ftp://ftp.digital.com/pub/BSD/bind/4.9
[Win Treese, treese@crl.dec.com]
editing your kernel configuration file add "options PACKETFILTER" add "pseudo-device packetfilter" rebuilding your kernel installing the new kernel booting the new kernel "cd /dev; MAKEDEV pfilt" to create the required entriesYou might also want to add the following lines to /etc/rc.local:
[ -f /usr/etc/pfconfig ] && {
/usr/etc/pfconfig +p +c -a 2>&1 & echo -n ' pfconfig' >/dev/console
}
This allows you to use promiscuous-mode applications, such as "tcpdump"
or "nfswatch". Note that the '-a' option to pfconfig allows any user to
spy on the network. If it is omitted, only root may do so.
There are also some patches for ULTRIX 4.2 and 4.2A for the packetfilter code. Call Digital's Customer Support if you need them. The official description of the patches is below; here is some background information. ULTRIX 4.3 has all of the patches included. Note: these patches cause DECnet-OSI not to work. To run DECnet-OSI on ULTRIX 4.3, you will need the latest patched version of net_common.o for 4.3.
Although not mentioned in the description, these patches should also make Ultrix more forgiving of certain incorrect 802.3 packets. Such packets are sent by some 3rd-party implementations. I don't think this will fix the problem in every case, since some Digital Ethernet interfaces filter out "bad" 802.3 packets in hardware. The patches should work for DECstations and most DECsystems.
Note that if you install these patches and you have been running CAP, you should recompile CAP after removing the definition for ULT42PFBUG from the Configure script. The ULT42PFBUG patch to CAP will not work once the kernel has been patched. You should also *stop* doing
ifconfig ln0 copyallonce you install the patches.
If you have been using tcpdump, nfswatch, or a similar monitoring program on an FDDI network, installing these patches will probably make that not work. You will still be able to use tcpdump on an Ethernet, of course. The reason for this is that tcpdump only worked on FDDI networks because of the bug that is fixed by these patches.
These patches are available for Ultrix 4.2 and 4.2A, and for both RISC and VAX. They must not be applied to previous versions of Ultrix.
Finally, note you must install new versions of BOTH net_common.o and pfilt.o; you cannot just install one of the files.
/sys/{MIPS,VAX}/BINARY/net_common.o
/sys/{MIPS,VAX}/BINARY/pfilt.o
-----------------------------------
(v4.2 RISC & VAX, v4.2a RISC)
Listed are problem resolved by these 2 patches:
1. PACKET FILTER FAILS TO RECEIVE UNICASTS TO LOCAL HOST
The packet filter mechanism is supposed to allow a user application to receive packets that are sent to the local host, if no other protocol in the kernel wants to use the packet. This worked fine in Ultrix 4.0 and 4.1, but in Ultrix 4.2 it is broken.
Apparently, setting "copyall" with ifconfig is a workaround, but this is an EXTREMELY inefficient workaround, and requires users to reconfigure their systems as super-user. This is not needed in ULTRIX 4.3.
2. PACKET FILTER IOCTL EIOCDEVP RETURNS WRONG MTU VALUE
A change was made to increase the size for ethernet packets from 1500 bytes to 1514 bytes which is the MAX size for the ethernet. This will allow 1500 bytes for the message and 14 bytes for the header.
Also corrected the value returned in endevp.end_MTU by the EIOCDEVP ioctl.
3. 802.3/802.2 PACKETS NOT PROPERLY DELIVERED TO PACKET FILTER
The packet filter is defined, in its manual page, to provide packets
to user applications exactly as those packets appear on the network.
The current kernel code mangles the headers of 802.2 encapsulations
of Ethernet packets, causing several popular applications to fail.
[Jeff Mogul, mogul@pa.dec.com]
There are several bugs in the Ultrix 4.2 packet filter mechanism, some of which affect CAP. These are fixed in ULTRIX 4.3. The details are complex, but you can solve one of them by doing (as super-user, probably from /etc/rc.local)
/etc/ifconfig ln0 copyall
(substitute whatever interface type you are using for "ln0"). The other bug, which apparently only affects CAP when "Phase 2" is in use, requires a patch to CAP. CAP patches are available from a number of archive sites, including ftp://gatekeeper.dec.com/pub/net/appletalk/cap/cap.patches
Another problem you may have is that some Ethernet interfaces sold for the Macintosh occasionally send incorrect 802.3 packet headers. (The bug is that they send a packet whose length does not match the value provided in the 802.3 header's length field. Ultrix 4.2, as well as some of Digital's Ethernet interface hardware, is strict about checking 802.3 header, and does not accept these packets.) As of this writing, a patch is not yet available and there is no workaround. If you can, you should try to get the vendor of the nonconforming interface to provide a solution.
Once you have obtained an up-to-date, fully patched copy of CAP 6.0,
the Configure script does not automatically switch on the workaround
code; you must manually edit the m4.setup file to turn the workaround
code on.
[Jeff Mogul, mogul@pa.dec.com]
pseudo-device gwscreenand rebuild your kernel (i.e., run /etc/config, then change to the right directory and do "make depend" and then "make"). Install the new kernel and reboot the system.
The error message that nfs_mount will give you if you are in too many groups will look like this:
nfs_mount: crltrx:/usr/local server not responding: RPC: Authentication error;
why = Invalid client credential
nfs_mount: access denied for crltrx:/usr/local
The workaround is to reduce the number of groups you are a member of to eight or less to make NFS mounts work again. In particular, you should check the number of groups that "root" is in.
NOTE: If you attempt to change the IP address of either the client or server without modifying the netblk then your DISKLESS CLIENTS WILL NOT BOOT.
The definition of the network boot block is in /usr/include/sas/mop.h and the netblk structure is shown below.
struct netblk {
char srvname[32]; /* server hostname (boot server)*/
unsigned long srvipadr; /* server IP address (boot server)*/
char cliname[32]; /* client hostname */
unsigned long cliipadr; /* client IP address */
unsigned long brdcst; /* broadcast address */
unsigned long netmsk; /* network mask address */
short swapfs; /* swap file system type*/
short rootfs; /* root file system type*/
short swapsz; /* swap size in 1/2 Meg units */
short dmpflg; /* dump flag 0 - disabled */
/* 1 - enabled */
char rootdesc[80]; /* root filesys descriptor */
char swapdesc[80]; /* swap file descriptor */
char reserved[20]; /* for later use */
};
In order to change the IP address of the client or of the server you will need
to modify the netblk.
The code for the boot block is in the file /etc/bootblk.c on the diskless client.
An example of this file is:
#includeA quick cross-reference with the mop include file will tell you which fields represent which data.struct netblk nblk={ "my_server", 0x10b38001, "my_client", 0x10b3803e, 0x10b380ff, 0xffffff00, 0, 5, 0, 0, "/dlclient0/my_client.root", "rz3b", "" };
To change the IP addresses you need to use the command /usr/diskless/makpkt.
The format of this command is:
makpkt server_IP_addr client_name client_IP_addr broadcast netmaskHere is an example of using makpkt to change the network boot block parameters.
For a server of address 16.128.128.4 and a client called fred of address 16.128.128.19 on a class B network you'll need to use the command:
% makpkt 16.128.19.4 fred 16.128.20.19 16.128.255.255 255.255.0.0this will produce the output:
0x10801304, "fred", 0x10801413, 0x1080ffff, 0xffff0000,You will now need to edit netblk.c and replace the line
0x10b38001, "my_client", 0x10b3803e, 0x10b380ff, 0xffffff00,with
0x10801304, "fred", 0x10801413, 0x1080ffff, 0xffff0000,The next step is to compile the new netblk.
% cc -c netblk.cIf you are changing the client IP address then you will also need to modify the CLIARP field in /etc/dlparam on the client.
eg.
CLIARP="16.182.128.61"
Finally you can change the server and/or client IP address on the server and reboot.
ONC RPC is a supported component of DEC OSF/1.
NobleNet provides ONC RPC tools and solutions for ULTRIX, UNIX, Windows (3.1/95/NT), Macintosh, VMS, OS/2, NetWare, VxWorks, etc.
NobleNet, Inc.
337 Turnpike Road
Southboro, MA 01772
Voice +1 508 460 8222
Fax +1 508 460 3456
mail:sales@noblenet.com http://www.noblenet.com/
echo -n 'disabling kernel routing: ipforwarding ' >/dev/console /usr/etc/kvar -k -wl -s ipforwarding -v 0 /vmunix >/dev/console
finger stream tcp nowait nobody /usr/etc/fingerd fingerd
NFS server: stale file handle _fs(21,154) file 410021 and 154 are the major and minor device numbers. 4100 is the inode number. Running 'ls -l' on /dev will show the device numbers, so you can ask mount what directory the filesystem is mounted on. Then use
find <file system> -inum <inode no> -printto find the file.
The multicast patches break the ULTRIX packetfilter. An unsupported version of pfilt.o that works with the multicast code is in
ftp://crl.dec.com/pub/DEC/multicast/pfilt.o
This patch should work with 4.2, 4.2A, and 4.3, but it is not supported.
[Lance Berc, berc@src.dec.com]
[Win Treese, treese@crl.dec.com]
The earliest version of ULTRIX that can handle DEC 1.3 Gbyte RZ58 drives
on DEC RISC machine is ULTRIX 4.2A.
[Jeffrey C. Gealow, jgealow@mtl.mit.edu]
The solution is to get more cylinder groups, either by using "newfs -c XXX" to specify the number of cylinders per group or by using 4096-byte blocks and 512-byte fragments.
Read the newfs manual page before trying this at home or work.
[Alan Rollow, alan@nabeth.cxo.dec.com]
[Win Treese, treese@lcs.mit.edu]
When newfs/mkfs runs it attempts to allocate enough inodes so that there are enough for an average file size of 2 KB. (bytes per inode = 2048). When there are enough cylinder groups this is easy. In fact, if the cylinder group is small enough, it may not get close to the MAXIPG limit.
But over the years, disks have gotten bigger. They have more cylinders, more tracks and the tracks have more sectors. As a result cylinder groups are larger and it's hard to allocate enough inodes to meet the 2048 bytes per inode limit, with only MAXIPG available. Since MAXIPG is fixed the effective average file size goes up.
On a News spool tree, the average file probably is around or less than 2 KB. As a result, these large cylinder disks don't have enough inodes for the typical file size, and, more importantly, you can't get more, since you're already at the MAXIPG limit. At least not easily.
But there are some solutions available...
Theme of solutions:
Inodes are allocated on a cylinder group basis. Want more inodes, use more cylinder groups.
1. Use fewer cylinders per group, thus getting more groups. See the -c option of newfs(8).
Note: On the 2nd hand advice of Gregory Neil Shapiro (gshapiro@wpi.wpi.edu) there are some disks for which the -c option won't work because mkfs(8) enforces a set of cylinder group sizes that won't allow reducing the number cylinders per below the default of 16. This seems to be the case for the RZ57 and RZ58.
2. Use a different file system block and fragment size; 4K/512a instead of the usual 8K/1K. In the case of News this may work best. Since most files are small, using the smaller size may help reflect the smaller average file size. It may also waste less space in partially filled fragments.
3. Lie about the geometry. If the track length or tracks per cylinder is nice factorable number, reduce one to increase the effective number of cylinders. By playing games with the factors of the geometry you manage to keep the geometry approximately the same.
For some disks this may not matter and you can invent whatever
lie you want. For example; the RZ58 uses zoned based recording
(banding). Depending on where you are on the disk, there will
more or less sectors per track. The single geometry presented
by ULTRIX is a convient lie.
[Allan Rollow, alan@nabeth.cxo.dec.com]
The message "out of gnodes" usually means "out of inodes" on the filesystem. To fix this, you can delete files or reinitialize the filesystem with newfs (after backing everything up!).
The message "gnode: table is full" means that the kernel table for keeping
track of open files is full. If you need to fix this, increase the maxusers
parameter in your kernel configuration file and rebuild your kernel.
[Jim Reid, jim@cs.strath.ac.uk]
[Alan Rollow, alan@nabeth.cxo.dec.com]
[Win Treese, treese@lcs.mit.edu]
If you like Modula-2, you might be interested in Modula-3, a successor
language to Modula-2 developed at Digital's Systems Research Center and
the (now defunct) Olivetti Research Center. A description of the language
and a portable compiler that runs on many platforms is available in
ftp://ftp.digital.com/pub/DEC/Modula-3
[Richard Sharpe, sharpe@adodem.enet.dec.com]
[Win Treese, treese@lcs.mit.edu]
Of course it's possible that a memory leak in the server still exists. If you think you have a memory leak, you should figure out which application you run that triggers the leak. You should run that application several times, observing the server size with every iteration. If the server grows by an appreciable amount each time, please file an SPR.
For workstations with minimal memory, we recommend that you use the following server command line arguments:
-once (restart the server afresh for each session) -su (inhibit save unders) -bs (inhibit backing store)The -su and -bs flags essentially trade CPU for memory, making applications work harder in some cases to save server memory. This tradeoff isn't as bad as it may sound.
XSessionManager*displayLogo: noTo replace the Digital logo with a different Encapsulated PostScript image, add the following to /.Xdefaults:
XSessionManager*logoFile: filename XSessionManager*logoFullScreen: trueMake sure that "filename" is the full path to a PostScript file. Note that the PostScript should not end with a "showpage" or the page will print and then disappear with the "new page."
UDXUNFONTS420 'Unsupported MIT Fonts'
UDXUNMAN420 'Unsupported X11 Reference Pages'
UDXUNMIT420 'Unsupported X11 Components'
These subsets, in total, provide the fonts, manual pages, and clients
from the X11 Release 4 distribution from MIT, with a few minimal
changes to fix problems that cropped up after the MIT release.
If all you want is R4 clients, load the above subsets. These subsets were built directly from the X Consortium sources and include all of the public patches. The R4 clients will be installed in /usr/bin/X11; put that directory in your path in order to access them. An ls on /usr/bin/X11 will also reveal the names of the applications that are available.
If you have a previous version of Ultrix, or if you need X11 Release 5, you will have to build from the X Consortium sources yourself. There are some difficulties associated with building Release 4 from source on Ultrix versions 4.0 and higher; fortunately, Release 5 corrects these problems, so be sure to start with a fresh Release 5 distribution.
Building from source should be a simple matter of editing the mit/config/ultrix.cf file and then connecting to the toplevel directory and typing ``Make World''. If you are running Ultrix 4.2, you don't need to edit ultrix.cf, but for other versions of Ultrix, be sure to cd to mit/config and change the OSMinorVersion (and, for versions of Ultrix prior to 4.0, the OSMajorVersion) number to the appropriate number for your version of Ultrix.
As mentioned in another FAQ answer, the Xdec server provides multiscreen capability for colour frame buffers, but features of Ultrix required to support this capability are not present prior to Ultrix 4.2; for those versions, the Xcfbpmax server will be built; this server only supports one display per machine, and only DECstation 2100 and 3100 and DECstation 5000 models running with the CX adapter.
The Xdec server should work on the following systems:
DECstation 2100 Monochrome or Color Workstations
DECstation 3100 Monochrome or Color Workstations
DECstation 5000/1xx CX, MX or HX Single or Multiscreen Workstations
DECstation 5000/2xx CX, MX or HX Single or Multiscreen Workstations
The support for the HX option on the above platforms is limited to
direct frame buffer I/O - the graphics processor present on the HX
board will not be used. This means that performance with the R5
server will be substantially worse than performance with the
DEC-supplied server in most cases. Support for the PX and PXG options
is not present in R5 in any form. Support for the MX exists, but some
problems have been reported when attempting to render non-black,
non-white pixels.
Source to X11 Release Five can be copied across the Internet from ftp.digital.com (16.1.0.2), crl.dec.com (192.58.206.2), or export.lcs.mit.edu (18.24.0.12). Other internet archives may also have full source distributions; asking around on the Usenet newsgroup comp.windows.x will probably elicit this information.
First, make sure the following subsets are installed:
UDXUNMIT420 UDXUNFONTS420You may also find the man pages for the previous two subsets useful. They're in:
UDXUNMAN420Next, add the following line to the end of /usr/lib/X11/config/site.def
#define StandardIncludes -I/usr/include/mitIf there are any README files with the source code, now is a good time to read them, and make any changes they suggest.
If you installed the MIT X11 distribution from MIT, rather than the ULTRIX subsets, your local configuration may be different.
If there is an Imakefile:
If the source code has a file called "Imakefile" at the top of its directory hierarchy, typing the following in that top-level directory should build the application:
xmkmf make Makefiles make depend makeTo install the application, type
make installIf there isn't an Imakefile:
You might have to edit the Makefile to make the application compile.
If ".h" files (like those for the Athena widget set, "Xaw") are not being found, adding "-I/usr/include/mit" to the "cc" command(s) in the Makefile will usually do the trick.
If you are having problems linking, try using "-lXext-mit" and "-lX11-mit" instead of "-lXext" and "-lX11" in the Makefile.
In order to optimize graphics performance, a tradeoff was made on both of these boards which prevents your system CPU from directly accessing display memory. Allowing your system CPU to directly access display memory would, at a minimum, cut the graphics accelerator performance by a factor of two, and perhaps more.
Unfortunately, as a result, operations which involve the copying of large images (Pixmaps) into or out of display memory are performed much more slowly than they would be if the processor were able to directly access system memory.
One example of this is the ever-popular background image. The X server keeps a Pixmap containing the pattern with which to paint the root window; whenever an area of the root window is exposed, the X server must copy that portion of the Pixmap over the relatively low-performance I/O channel to the PX or PXG adapter, which then copies it into display memory.
As a result, iconifying and deiconifying windows can become a fairly slow experience, particularly on systems with lower TurboChannel bandwidth. In this case, the solution is simple; just use the standard, boring background. However, if an application that you use actually needs to copy Pixmaps to the screen on a regular basis, you will definitely experience slow performance; there's no way to fix this problem.
Unless you need the vector performance of the PX or the 3D rendering
capabilities of the PXG, use one of the several boards DEC produces
which are optimized for windowing and imaging, such as the CX (dumb
colour frame buffer), MX (dumb monochrome frame buffer), HX (smart
colour frame buffer), or TX (imaging colour frame buffer).
[Author lost.]
Memory array module types are:
MS01-AA 1Mbit DRAM DS2100,DS3100,PDS5000/20,PDS5000/25,DS5000/120,
DS5000/125,DS5000/133
MS01-CA 4Mbit DRAM PDS5000/20,PDS5000/25,DS5000/120,DS5000/125,
DS5000/133
MS02-AA 1Mbit DRAM DS5000/200,DS5000/240
MS02-CA 4Mbit DRAM DS5000/200,DS5000/240
However, you can place one memory array module of a smaller capacity
at the end of a series of higher capacity modules.
Slot Module
0 MS02-CA
1 MS02-CA
2 MS02-AA
This configuration will work, and be properly recognized by Ultrix,
but it is not "supported." The console will see all of the memory
modules. The operating system will be expecting memory in 32MB
segments and when it hits slot 2 it will simply believe that there are
24MB of failed memory on that module.
It will not be possible to support higher memory congigurations in the DS5000 series machines with 16Mbit DRAM cards. The issue is that both the physical memory address and the I/O address are provided by the same Kseg0 block (512MB) in the R3000. This will not change with the advent of the R4000 daughter cards, as it would require modification of the memory controller ASIC (the MT chip) as well.
DS5000 then it's a 5000/200.
DS5000_100 then it's a 5000/1xx (where xx={20,25,33})
DS5000_300 then it's a 5000/240.
DSPERSONAL_DECSTATION then it's a 5000/xx.
For something more specific on the 5000/1xx and 5000/xx, you need to
look at the messages printed out at last boot time (available in the
error log; use /etc/uerf -R -r 300).
1. Remove the graphics stuff.
2. Put a mouse loopback connector in the hole for the mouse
plug.
The loopback connector part number is: 12-25628-01
To make your own:
Short Transmit data to Receive Data, o 1
pins 2->4 as shown in the diagram. 7 o +-+ o 2
(view looking at the plug). 6 o | |
5 o +-+ o 3
o 4
To run a DECstation 5000/2xx without the display:
1. Remove the graphics card, keyboard and mouse. 2. Connect the character terminal to the serial port labelled "3". (9600bps, 8N1, data leads only).
Digital's RISC machines all use IEEE floating point representation with a little-endian byte ordering. You can easily convert between little and big endian ordering by reversing bytes within the floating point number.
The VAX line uses a unique (although, given the popularity of VAXen) quite well known floating point format.
The ULTRIX C libraries include routines which will translate between RISC (IEEE) and VAX floating point formats. Look under "ftoi" in either the online or hardcopy documentation.
mount/foreign/block=10240/record=10240 mua0: copy mua0: file.tarOn Ultrix:
dcp -i 'vms::where$logical:file.tar' file.tar
The second reason is that Digital depends more on "personal" use of an
operating system, and tries to break up the costs of providing an
operating system depending on the number of users using it. Rather
than charge a larger amount of money for a two-user system, Digital
charges a base amount of money, then distributes the rest of the
development costs across the per-user license base. Digital hopes
that this gives an equitable and affordable system to all customers.
[Jon "maddog" Hall, hall@zk3.dec.com]
To join the list, send a message containing:
subscribe decstation-managersto majordomo@ornl.gov. To subscribe an address other than your return address, such as a local exploder, add that address to the subscribe command, e.g.:
subscribe decstation-managers decstation-managers@foo.bar
MODEL
NUMBER DESCRIPTION
---------- -----------------------------
1 QB-0JRAA-E5 Ultrix/UWS Edu Source Code
2 QB-0JRAA-EM Ultrix/UWS Edu Source Code
3 QB-0JRAE-E5 Ultrix/UWS Edu Source Code
4 QB-0JRAE-EM Ultrix/UWS Edu Source Code
This is a little confusing, since the "DESCRIPTION" of all four kits is
the same. As far as I know, you need to order the -0JRAA- kit the
first time, and the -0JRAE- ("update") kit for subsequent releases.
Probably, this is so that you don't have go through a complete set of
paperwork for a new release. You have to have to meet a number of other
requirements; see the Software Product Description (SPD) for more details.
The -E5 kits are on TK50, and the -EM kits are on 9-track magtape. I don't believe that the source kits are available on any other medium.
All 4 part numbers have the same list price (not especially expensive). I don't know if they are available outside the US.
If you're not at an educational institution, here are the corresponding part numbers (these are listed in the SPD, by the way):
MODEL
NUMBER DESCRIPTION
---------- -----------------------------
1 QB-0JQAA-E5 ULTRIX WS LOC.USE SOURCE TK50
2 QB-0JQAA-EM ULTRIX WS LOC.USE SOURCE 16MT
3 QB-0JQAE-E5 ULTRIX WS LOC.USE SOURCE TK50
4 QB-0JQAE-EM ULTRIX WS LOC.USE SOURCE 16MT
These are more expensive.
[End of FAQ]