In the past, getting patches required a service contract, but that has changed with the introduction of HP Support Line (HPSL). If you have a service contract, you can still get patches from your support rep.

The following is an excerpt from the official HPSL announcement from HP:

"The HP SupportLine mail service is a simple, yet effective, way for you to retrieve support information from Hewlett-Packard via electronic mail.

"Using the HP SupportLine mail service, you can:

• Resolve software problems by searching up-to-date support and problem-solving information;
• Identify and download available HP-UX or DOMAIN software patches; and
• Subscribe to automatically receive the latest Hewlett-Packard support and/or patch information."

ADUS stands for Apollo Domain USers group. ADUS is the predecessor of Interworks, a large non-profit organization not officially related to HP/ Apollo. Interworks has a magazine (free subscription) and an archive site (iworks.ecn.uiowa.edu) with plenty of software. It also sponsors conferences and workshops (which are not free). Although Interworks is a group for HP (3000, 9000 series) and Apollo (DN series) computer users, its primary focus seems to be leaning towards HP boxes. To become a member of Interworks, contact:

[2.0] USER AND ENVIRONMENT

Nope. You have to use the vt100 emulator (which is loaded automatically when you run vi, unless you're trying to do it remote). You can also use an xterm.

We have been using Leonard N Zubkoff's (lnz@dandelion.com) Apollo customized versions of GNU Emacs on our Apollos for some time now (latest version we have installed is 18.57). A month ago I started using X. I quickly discovered that all my Apollo function key and keypad key bindings (the gray keys), no longer worked. These bindings were made in my .emacs file using Zubkoff's supplied function, bind-apollo-function-key, which is defined in /gnuemacs/etc/apollo.el.

This meant, I first thought, that I would have to go through the painful process of figuring out how to bind emacs functions to the gray keys under X and then modify my .emacs file accordingly. After talking to others who had done this, I felt there had to be a better way, and there is!

The file x-apollo-keys.el solves the problem. All Apollo keyboard gray key bindings made in your .emacs file, which work under the DM, will now work under X, as well. The same .emacs will work for both.

All you have to do is place x-apollo-keys.el in your emacs load path and then add the following line to your .emacs file:

BEFORE any call to bind-apollo-function-key in your .emacs file. That's it!

Gnu Emacs 18.55 (with Leonard N. Zubkoff's patches for SR10.2) seems to have a problem with shell subprocesses. At times the 0x0 character (displayed as ^@ by Emacs) appears in buffers running a shell. While this is only a nuisance running an inferior shell, it is a problem when running the M-x compile command: The C-x ` (next-error) function is unable to process the compiler output. Has anybody found out what causes this problem and how to fix it? Any hints will be appreciated!

Emacs talks to its subsprocesses using pseudo ttys (ptys among friends). On Apollos, ptys occasionally get corrupted, and the problem you describe results. Rebuilding the ptys helps, but it can have funny side effects to any users logged in on those ptys. We rebuild ours once per week. That seems to avoid the problem most of the time, but of course your mileage may vary. Here is the relevant line from our /usr/lib/crontab (running the shell script at 04:00 every Sunday morning):

All you need to do is configure /etc/ttys to allow root login via pseudo-ttys (if you really want to):

        pty0 none dumb on secure
        pty1 none dumb on secure 
         . . .
        ptyf none dumb on secure

  getla()
  {
      long avenrun[3];
      proc1_$get_loadav(avenrun);
  }

There is an Apollo assembler, which you may be able to get. It isn't a supported product.

You can also use the gnu assembler. It is part of gcc (see above), or you can ftp it from /pub/apollo/local/lib/gcc-as at ftp.eb.ele.tue.nl.

[Maintainers note: If someone knows where to acquire the Apollo assembler, please send the information to kolya@zepa.net for inclusion in the faq.]

>I am working on Apollo 3500 workstation. There I am unable to use vi. If I
>try to run vi, it says "Apollo-color-15-terminal" and vi does not function
>properly. If I try to run /com/vt100, it says "Can not create vt100
>window". Can someone suggest some way out?

Your pty device files are probably corrupt. This sometimes happens when there is a system crash or when you use Emacs, which has a tendency to orrupt pty's. Simply remake them with the command:

Yes. An update to the Emacs v.19.22 version of compile.el which can parse the Apollo 6.9 BSD C compiler error output is available from ftp://ftp.wfu.edu/usenet/apollo/src/compile.el-apollo.gz

The patches and instructions on how to compile httpd-1.3 on an Apollo running Domain/OS 10.4 is available from ftp://ftp.wfu.edu/usenet/apollo/src/httpd-1.3-apollo.gz

The authors of Mosaic made the unfortunate decision to use Motif instead of one of the free widget sets. So if you want Mosaic, you can compile it yourself if you have Motif, or you can get a binary from someone who has already compiled it.

There is another browser called chimera. It uses the Athena widget set, which is free and included as a standard part of X11 (but inexplicably left out of HP's software releases). I use it all the time and like it a lot. It's available from ftp.cs.unlv.edu.

[3.0] X-WINDOWS AND DISPLAY MANAGER

X11R4 shared client libraries are available in binary form by FTP from archive.umich.edu. X11R4 sources are available from a number of FTP sites, including:

• ftp://gatekeeper.dec.com/pub/X11/R4
• ftp://mordred.cs.purdue.edu/pub/X11/R4
• ftp://giza.cis.ohio-state.edu/pub/X.V11R4
• ftp://uunet.uu.net/X/R4
• ftp://crl.dec.com/pub/X11/R4
• ftp://src.doc.ic.ac.uk/X.V11R4
• ftp://munnari.oz.au/X.V11/R4

Jim Rees has compiled the X11R5 libraries, including X, Xt, Xaw and Xmu. It is available from ftp://apollo.archive.umich.edu or archive.umich.edu.

If you have a service contract, HP offers X11R5 for SR10.4 as a part of the standard software support contract as of 93. The tape includes X11R5, Motif 1.2 and HPTerm 1.3

Also, HP has made available via its InterWorks users group the following distributions:

• source and binaries for the entire generic MIT X11R5 Core Distribution (Including a sample server); and
• source for outdated or sample X user interface products.

X11R6 is due in early Spring. When a port becomes available, we'll include details in the FAQ.

The X11R5 server is included into SR10.4.1. It is not included into the SR10.4.1.p (the DN10000 a88k release). Xdomain would be the R5 server, Xapollo the R4. In 10.4.1's release notes, HP said that if you want to use both Xapollo and Xdomain you will either need to keep two font directories (as R4 and R5 use different font formats) or run a convert program every time you switch.

SR10.4 includes X11R4 as Xdomain and X11R3 as Xapollo. They use the same font format, so you can run both simultaneously.

You need to install "psk5." This should be available from your friendly HP/Apollo sales office. The problem is fixed in SR10.3.

Your R4 clients will normally work fine with the Apollo share-mode R3 X server. The psk_q3_91 patch from Apollo includes some R4 client libraries (except Xaw, the Athena widgets) and a server that runs simultaneously with DM, but rather than sharing the screen, you switch between them with a hot key. This server is called Xdomain. This patch is available by anonymous ftp from ftp://hpcvaaz.cv.hp.com/pub/apollo/pskq3_91. You can get shared R4 client libraries in binary form by ftp from archive.umich.edu. R5 clients will normally work with either Xapollo or Xdomain R4 servers.

        xtiff.c: 63: Unable to find include file 'X11/Xaw/Form.h'.
        xtiff.c: 64: Unable to find include file 'X11/Xaw/List.h'.
        xtiff.c: 65: Unable to find include file 'X11/Xaw/Label.h'.

Your application was written for X11R4/R5, and your Apollo only has X11R3. HP/Apollo now suppports X11R5 (see above on how to get it), although their idea of "support" doesn't include a number of shared libraries...

The manual "Using the X Window System on Apollo Workstations" is the place to look for some of this - it's a good summary, but not an exhaustive treatise on X. The answer to your question is that you will need to use the client "xmodmap" in order to simulate the keys which are not physically present on the Apollo keyboard (PF1-PF4 as an example).

Since you are running in a "dm owns root" configuration, you'll need to take into account the "keyboard.config" file which tells XApollo "this list of keys doesn't exist for X, pass them through to the Apollo Display Manager". This is important because you don't want to remap keys for xterm which XApollo will not GIVE to xterm. See section 2.2.2 in the manual for a detailed discussion about the /usr/lib/X11/keyboard/keyboard.config file.

Once you have picked a set of physical keys to emulate the PF keys, feed this to xmodmap using the physical keycode and the keysym name (from the include file /usr/include/X11/keysymdef.h).

Example - you want to make the "AGAIN" key map to PF1. Looking at the output of "xmodmap -pk" you see that it is labeled "Redo" (which agrees with the entry in the keyboard.config file), and it is keycode value 158. Looking at the include file keysymdef.h, you see "#define XK_KP_F1 0xFF91" which is the entry for "keypad function key 1" - also known as PF1. The xmodmap client will take either a file entry or a command line remapping, so you could invoke it as < xmodmap -e "keycode 158 = KP_F1" > (the quotes are required on the command line) and the deed is done.

If you don't have a copy of the manual, you can get one by using the order number "015213-A02". Hope that helps."

I suggest you put the following into /usr/X11/lib/XKeysymDB :

        LineDel:        1000FF00
        CharDel:        1000FF01
        Copy:           1000FF02
        Cut:            1000FF03
        Paste:          1000FF04
        Move:           1000FF05
        Grow:           1000FF06
        Cmd:            1000FF07
        Shell:          1000FF08
        LeftBar:        1000FF09
        RightBar:       1000FF0A
        LeftBox:        1000FF0B
        RightBox:       1000FF0C
        UpBox:          1000FF0D
        DownBox:        1000FF0E
        Pop:            1000FF0F
        Read:           1000FF10
        Edit:           1000FF11
        Save:           1000FF12
        Exit:           1000FF13
        Repeat:         1000FF14
        KP_parenleft:   1000FFA8
        KP_parenright:  1000FFA9

This will let you refer to these keys by name. For example, the following resource will define scroll keys for your xterm. You can put this resource into your ~/.Xdefaults file and it will get loaded when you start an xterm:

        XTerm*VT100.Translations: #override \
                UpBox       : scroll-back(1,halfpage) \n \
                DownBox     : scroll-forw(1,halfpage) \n

If you use emacs or motif, you may want to define a "meta" key (motif calls this an "alt" key, presumably because IBM has some pull at OSF). You can do this by creating a ~/.keymod file, an put this in it:

        clear mod1
        keycode 147 = Meta_L
        add mod1 = Meta_L

This makes F0 your meta key. You can use whatever key you want as your meta, of course. Use xev to find out the keycode for the key you want. Then, when you log in, run this command (I put this in ~/.xsession, which gets run on my machine when I log in):

        /usr/bin/X11/xmodmap .keymod

To convert from a DM font to an X bdf font, run edfont on the DN font, and save it as bdf. Then you can go ahead and run bdftosnf and mkfontdir as usual. Details below.

You do need to make one adjustment. X fonts have no concept of inter- character spacing, so you have to add the spacing to each glyph in the font.

Copy the DM font to a file with the name you want the X font to have, for example f7x13b. Then start edfont on that file. Go to "font params" under the "font" menu and look at "inter char spacing." Remember that number, and hit "no changes." Now go to "+- glyphs," also under the "font" menu, and enter that number under "Change printing widths." Now hit the "change all glyphs" button. Next, go to "save as..." under the "file" menu, select Adobe BDF, add ".bdf" to the end of the name, and save it. Exit edfont ("exit" under the "file" menu).

Now run bdftosnf on the file, add it to some directory on your font path (see "man xset" for info about font paths), run mkfontdir on that directory, do "xset fp rehash," and you're done. Wasn't that fun and easy?

While perusing the system in my spare time (now that I'm a lowly user, I have spare time :-) I re-noticed the type managers, and the large amount of space that they consume. I'm certain that most of them are not needed for any given system. I'm pretty sure that many of them aren't needed, even if you allow for diskless booting, at least in our environment. What I don't know is which I can have pulled off safely. In other words, I need to know what systems the following managers take care of.

As was previously mentioned llkob will tell you which managers are in use on a specific system. Beyond that display type managers at the /sys/mgrs level are used by G*R, while the type managers in /sys/mgrs.split are the X display libraries. Those named xdl_trait are used by Xapollo (the share mode server). xdl_trait.2 are for Xdomain (the borrow mode X server).

Here is my best attempt to match type name with a device:

        dtm_fm         dn2500 mono and mono VRX on Series 400
        dtm_kat        VRX on series 400 (1280x1024)  color12
        dtm_tsg2d      PVRX (VRX P1 P2 P3) on Series 400 color13
        dtm_wood       425e/433e built in graphics EVRX (1024x768 & 1280x1024)
                       controller15
        dtm_color14    CRX (color & grayscale) on Series 400 color14
        dtm_mono_big   mono 1280x1024 on dn series bw4
        dtm_mono_small mono 1024x800 on dn series bw5
        dtm_color4     4 plane 1280x1024 on dn series (C graphics) color4
        dtm_dn10000_8  8 plane 1280x1024 on dn series (E graphics) color5
        dtm_mk3        8 plane 1280x1024 on dn series (F graphics) color6
        dtm_mk3_4kpage DN5500 version of dtm_mk3 (?)
        dtm_color7     8 and 40 plane DVS on dn series

[ Maintainer's note: also dtm_dn10000_vs is the 1280x1024 40/80 plane DVS (X-Bus on DN10000) manager. ]

WW is an undocumented DM command to do word wrap on the currently selected region or to set word wrapping mode for text subsequently entered. Options:

        -ON   Turn on word wrap and set column at current right margin
        -OFF  Turn off word wrap
        -C nn Turn on word wrap and set column at specified value
        -A    Wrap selected region
        -I    Query current column setting

Graphics on Apollo is usually library-based. There are several libraries available, but some of them are optional products that you would have to buy. In any case, you will need a compiler (probably C, but Pascal and Fortran will be OK). The libraries are:

• GPR (Graphics Primitives Resource): this is provided with the operating system (/lib/gprlib), and its header file is either /sys/ins/gpr.ins.c (.ftn, .pas) or /usr/apollo/include/gpr.h. GPR is a 2D (2-dimensional) library and can draw lines, polygons, arcs, circles, text, etc. You can control colours, styles, etc. You can clip, BLIT (block transfer), perform logical operations (such as OR, XOR), and so on. In fact, the Display Manager is written mainly using GPR!

  If you use the pad_$... calls, you can put GPR graphics into a pad (window) in "direct" mode. Otherwise, you can use "borrow" mode and your application will fill the whole screen.

  GPR is quite powerful, and it is probably the best library for you to start with.

• GSR (Graphics Service Routines): this is also provided with the operating system. I believe that GPR actually uses GSR. GSR is lower-level than GPR, which means that it's more difficult to use, but if you work hard, you can make very fast graphics applications.
• GKS (Graphics Kernel System (I think)): optional product. This is a 2D library that has "metafile" (or "display list" or "structure") data management. This means that your application draws pictures into data structures, and then GKS displays the contents of those structures. Useful for 2D CAD applications.
• PHIGS (Programmer's Hierarchical Interactive Graphics System): This is another optional product (you have to buy it). This is like GKS, but it is 3D. It is an industry standard (so is GKS).
• Xlib: If you want to run the X server on your Apollo, you can write Xlib programs, which are 2D. But you need an optional product called UEDK (User Environment Developer's Kit, see below).

Xlib: SR10.4 and 10.4 already include the X11R3 includes and libraries required to build applications. However, you still need UEDK for X11R4 and R5 applications.

There is also GMR2D and GMR3D (GMR2D is a provided with the OS, not sure about GMR3D) which allow you to draw using metafile, similar to how GKS is described above.

[4.0] SYSTEM RELATED SOFTWARE

Sendmail 5.61+IDA is available from ftp://eng.clemson.edu/mail+ftp. For some small patches to make it run better under Domain/OS, ftp the file sendmail.5.61-apo.Z from maths.su.oz.au.

Also, check out Neil Rickert's version of sendmail 5.65 with the IDA enhancements available from ftp://uxc.cso.uiuc.edu/pub/sendmail-5.65+IDA-1.4.2.tar.Z

Rumor has it that SR10.4 comes equipped with sendmail 5.65b+IDA-1.4.3, which supports MX records.

If you need a version of sendmail which requires delivery of several thousand messages each day, the following solution is suggested:

Are there sites out there that deliver or queue 8,000 - 10,000 messages a day on/through their [Apollo Token] ring? We do.

Three mods to mail are required to handle this volume of mail.

1. use dbm files for /etc/passwd info, and do not query the rgy all the time.
2. use nR_xor_1W concurrency control and not cowriters, so you are able to have different nodes process files without regard for which node has the disk attached.
3. have sendmail "tempfail" errors like ios_$concurrency_violation, and get clues from the difference between ios_$name_not_found and ios_$object_not_found. Along with #2, this makes alias files much easier to deal with. Also makes it harder to miss someone's forward file.
4. display the apollo error text, and not just the perror() text. if you see things like sfcb allocation failures, or can't lock pipe errors, just go ahead and reboot.

If you use the rgy, and do any volume, you need to make sure that any 0 returned by getpw routines is not accompanied by an errno. if you use the /etc/passwd approach, you will get your errors at open time (you hope) but we have seen hours and hours go by and still a machine will not successfully get the rgy data cached into `node_data/systmp.

When we quit using the rgy, we discovered that we ran into other problems, like not getting sfcbs, having mutex locks never released by processes trying to get an IP route, and other fatalities. So, I call proc2_$list() and see how many procs are running. The load average is not sufficient because the # of procs can get quite large without appreciably bumping the load ave.

Anyway, I don't know offhand what arrangements the "king james" or IDA releases make for apollos, but in my experience the aforementioned ones have been crucial here.

We also spike a dec3100 at load aves. of anywhere from 40-60 doing news and mail, so after a while, you just get used to "big mail."

Having said all this, the apollo/domain file system architecture is really very good for doing the definitive distributed mail environment. We do run into loading problems and plain old bugs, but we could not provide the scale of service we do now on anything but apollos, quite honestly.

One hopes that other distributed or networked file systems will get better and have features that support the same sort of functionality I've gotten used to on apollos.

The Apollo file system uses mandatory, implicit locks. The Apollo mail system has never been fixed to properly deal with this.

Mail is usually delivered to the spool file by /bin/mail. If /bin/mail is busy delivering mail when you try to collect it, you will be unable to open the spool file. If you are busy collecting mail when /bin/mail tries to deliver, then sendmail will see the infamous "unknown mailer error 1."

As far as I know, /bin/mail doesn't use any other locking scheme. It can't use flock(), since flock() can only be called on open files. It may use .lock files but I doubt it.

The proper solution to all this is to write a new version of /bin/mail that retries on locked spool files, and make sure all your mail reading agents keep the spool file open only long enough to collect the mail, and also retry on locked files. Apollo should do this. You shouldn't have to. Don't hold your breath waiting for this to happen.

I think Apollo patch pd91-m0336 (Oct 1, 1991) fixes the mail file locking problem that results in the "unknown mailer error" message from sendmail.

Many people have written programs to call the DM editor from a program and wait until it exits. For one solution, ftp the file dmedit.tar.Z from maths.su.oz.au or ftp.eb.ele.tue.nl.

I got ours just from either the NET or from the SUN lifeline mail package. I can't remember having to tweek it hard. (at least no notes of that). The only thing is that it runs wild now and then, it swamps the node with popd's ( >100), and the node has to be shut. Also is there a protocal violation on something, since the popd image goes to the ZOMBIE state and stays there until a new popd request comes in.

We're running 10.3.5 and 10.3.5.7 Full BSD. You can get our executable:

There are several versions of Apollo NFS, each with varying degrees of reliability. NFS 2.1 with patch 186 seems to be fairly stable, and others use NFS 2.3. NFS 4.1, which includes NIS, has been out for some time now, and it is reportedly also fairly stable. It is an extra-cost product.

For performance reasons, mounting // is not recommended. Doing this requires the node exporting // to handle ALL NFS traffic, and all NFS accesses will be converted to 2 remote file system calls; one to access the NFS server, and the second for the NFS server to access the remote DFS file system. This also creates a huge network bottleneck. The recommended action is that you run NFS 4.1 on all nodes and mount them independently as if they were ordinary Unix machines with NFS out there on the net.

One way to do this [mount all nodes independently] is to use the automounter. We have a modification of this. It allows us to use the automounter and have '/' mounted, but to also have Apollos that can't or won't do NFS to still be seen.

• Set up a /nfs directory for automounts
• Start up the automounter --> /usr/etc/automount /nfs -hosts
• Set up a directory /net full of links
  • If the remote node can handle NFS set up goodnode's exports file to export '/' create a link /net/goodnode -> /nfs/goodnode
  • On ONE node (//master) set up master's exports file to export '//' create a link /net/master -> /nfs/master/master
  • If the host doesn't have NFS, or is really pokey/unreliable create a link /net/badnode -> /nfs/master/badnode
• Have everyone go through the /net directory (not the /nfs directory)

The majority of the nodes should be "goodnode" types. They will have NFS loaded, they will have / exported, they will respond in a timely fashion,...

A few nodes will be horribly unreliable, for whatever reason. These nodes will be looked at by the Un*x box by going through //master's mount one level further.

The master node will export everything, so accesses to it must go one level beyond the /nfs/hostname level too.

This scenario does a few things for us. First, we have a fallback method of getting at a remote host if the NFS fails -- link /net/thathost to /nfs/master/thathost, and it all works (albeit more slowly). Second, it is allowing us to transition from having // mounted (and people expecting to go to /net/DDS/nodename) to having lotsa /'s loaded, and people going to /net/nodename (we made a /net/DDS that points to . on the automounter nodes). We can still mount // if we need to, and in fact, a few Un*x boxes are giving us some grief, for whatever reason, with the automounter. Most important, though, it is getting us TOWARD having each node responsible for its own disks; we don't have a sudden transition, but we have a definite movement to this goal.

> A subnetted node on the token ring has an external drive on it which in
> turn has a directory I want to nfs mount from an rs6000.  The subnetted
> node is running damd and the gateway is running the full nfs 2.3 suite.
> How?

The damd is not used when a foreign system mounts an Apollo -- it's used when an Apollo wants to borrow a mount that another Apollo has made (often a mount into the // area, but not exclusively). It allows //nodeB to access the NFS mount point as //nodeA/foreign-system-name, rather than having //nodeB mount the foreign system into its own filespace.

> Linkwise the setup looks something like
>   //gateway/xdisk/dirname -> //subnode/xdisk/dirname

Nice, but not necessary.

> and on the rs6000 I would like to mount gateway:/xdisk/dirname as
> /rsdirname. Can someone give me a few hints on how to go about getting
> this to work?

You can go about this in either of 2 ways:

1. The "proper" way is to have //subnode export the file system, and have the IBM mount subnode:/xdisk/dirname. This involves loading NFS 2.3 on //subnode, editing the /etc/exports file, having the mountd and portmap daemons running, using exportfs, and all the other nasty NFS things that good-old-Apollo managed to ignode in their superior file system.
2. Cheat. Edit the exports file of //gateway, and put in an entry for //subnode/xdisk/dirname (unless you already export //subnode/xdisk, //subnode, or //). On the IBM, request a mount of gateway: //subnode/xdisk/dirname. If you still have the broken-IBM NFS that messages pathnames and strips out the // in the mount request (a bad thing that shouldn't be done), then I believe the work-around is to request a mount of gateway:/../subnode/xdisk/dirname instead.
3. Cheat even worse. If you can't get the IBM to mount //something-or-other and it won't take /../something-or-other, then do the following -
   • remove the link //gateway/xdisk/dirname
   • do a /com/ld -u -ent //subnode/xdisk/dirname
   • note the UID (the 8-digit.8-digit value)
   • do a ctob //gateway/xdisk/dirname UID-path-from-above
   • put //gateway/xdisk/dirname in the exports file, and have the IBM mount gateway:/xdisk/dirname.

In that third method, you just created an object on the //gateway that has the UID of the object over on //subnode. It's equivalent to a hard-link, except that it can cross file systems, and if it does, it doesn't increment the link-count of the object. If you chate this way, though, I'd be very very careful to not do a dlt on the object. If you want to remove the hard-link equiv, do an 'uctob pathname' instead of a rm or dlt.

As in all things, there is an easy way and a hard way.

The easy way:

        ftp://ftp.eb.ele.tue.nl/pub/apollo/local/etc/pcnfsd.v1
         or
        ftp://ftp.eb.ele.tue.nl/pub/apollo/local/etc/pcnfsd.v2
        ftp://ftp.eb.ele.tue.nl/pub/apollo/local/man/{m,c}atl/pcnfsd.l

Which should get it all to work. (Don't try pcnfsd.new, since that's the version 2 I'm working on, which supports membership to multiple groups, but has printing sort of messed up.) Go to /usr/adm, touch the file pcnfsd.log and from there execute the pcnfsd. You get a nice log, which needs to be cleaned on regular occasions.

The advantages of version 2 over version 1 are:

• Membership of multiple Unix groups, when the PC-NFS version understands it. (Sun PC-NFS v4)
• Looking in the printer queues. This requires a SysV mechanisme like lpstat, .... which we don't have since we're running BSD-only. (and printing with prf :-{ ) So I'm hacking the source to get it to work at our site. Maybe one day we'll see a version which understands both.

Now I've compiled this set with RPC version 3.9, and the most recent one is 4.0.

So you might choose the hard way:

• Get the RPC stuff, archie could tell you where.
• Get the code for the ftp-deamon (/pub/apollo/pcnfsd.v1.3.tar.Z)
• And just compile to only make the library and then compile the pcnfsd. It's not all that hard.

(Note: I keep a version with some changes to have it easier compile on Apollo's in /ftp/pub/apollo/sunrpc3.9a.tar.Z, which is used uner 10.3 )

Anonymous ftp depends on the chroot() call, which doesn't work on Apollo. There is a patched version of ftpd that supports anonymous ftp by fixing all path names before passing them off to the system. It's available (by anonymous ftp!) from various places, including ocf.berkeley.edu, archive.umich.edu, and ftp.eb.ele.tue.nl.

Proxy ARP is a bad idea. Apollo has wisely decided not to support it. Use subnets instead.

Uncomment the 'nmconfig' lines in /etc/rc.local. Create the empty file /etc/daemons/nmconfig. Create the file /etc/resolv.conf. It should look like this:

        domain          domain-name
        nameserver      server1
        nameserver      server2
        nameserver      server3

where domain-name is your domain name, and server1..n are the numeric IP addresses of your name servers. You can have as many as you want, it tries them in the order listed. Here's a sample file for pisa.citi.umich.edu (IP addresses are fictional):

        domain          ifs.umich.edu
        nameserver      10.3.27.4
        nameserver      10.1.27.4
        nameserver      10.1.33.2

The SR10.2 version of routed would stop broadcasting and listening to RIP routes after about 20 minutes. This is due to a feature in DomainOS which keeps applications from receiving their own broadcast packets. BSD routed depends on this feature in stand-alone networks to determine if there is a problem with the physical interface.

From the SR10.3 release notes:

4.2.4 TCP/IP Bug in routed

The routed command does not detect an inactive physical interface unless the interface is specifically configured "down" with the ifcon- fig command.

SR10.2 routed aged active routes (APR 000DDC72)

The routed command was timing out active physical interfaces. We've modified routed to prevent it from timing out, and therefore marking "down", interfaces that are configured "up" with the ifconfig command. The routed command does, however, time out interfaces that are configured "down" with the ifconfig command.

If you are finding that anything depending on TCP/IP to a remote site (i.e rlogin, ftp) disconnects you with a Network is unreachable error after a short delay & everything looks okay, yet such things work to machines on the same site or subnet, then try the following: change the following line in /etc/rc.local

to

This turns on directed broadcasts for gateway routers and turns off the pinging of gateways (which is a weird thing to do, as attempting a connection through a gateway is a pretty good test to see if its up + RIP packets should keep one informed).

I suggest that you use the '-q' option to routed if the apollo is not a router itself. Also make sure you've got your netmask right. Finally, if all else fails, just install the routes manually with /etc/route and don't use routed.

DOMAIN TCP/IP does support SLIP and I use it all the time from my sr10.3 DN3000 at home connected via a pair of Telebit T2500s running v.32 to a cisco terminal server. The DCE/DTE connection is at 9600 baud; CTS/RTS flow control is enabled in the modem and the node. I dial up to work using emt, get connected to the terminal server, give it the "slip" command (which tells you what IP address you've been assigned and then puts the line in SLIP mode), exit emt, and do something like:

    /etc/ifconfig sl0  
    /etc/route add default  0

It all works passably well. It's hard to know which nuisances to attribute to the modems, the phone line, SLIP in general, or DOMAIN TCP/IP. It works well enough so that I haven't delved into it. (I used to use Telebit PEP mode, which is pretty awful for SLIP, but barely tolerable. My current nuisance seems to be that the T2500s have some sort of bug that cause them to hang the connection after an hour or so of use. Others have reported these symptoms on comp.dcom.modems in a non-DOMAIN environment, so it looks like a modem, not a DOMAIN, bug.)

The slip MTU is fixed at 1000. If you're using a slow line, you may want to start tcpd with the -p0 option (see the man page).

Domain TCP/IP does not support CSLIP (compressed SLIP) and PPP (Point-to Point Protocol).

Yes. For those people who do not have access to a remote SLIP server, you can use TERM. Term allows you to have multiple login sessions, run X, do redirection (a TCP/IP connection to a local port is rerouted transparently to a port on any machine on the Internet) and supports software data compression and error correction all over ONE serial connection. I ported Term 1.07 to my DN4500 and used it with 2400 baud modem, and received throughput (ASCII text) of about ~600 cps. I've unfortunatley lost my patches, but Term 1.12 (as of 2/25/94) compiles nearly out-of-the-box. The 5-10 lines I changed dealt nearly entirely with function prototypes, so I didn't make a src diff. If you have trouble with it, bounce me some mail, and I'll send you a patch.

I've noticed that term 1.12 becomes rather choppy, even with one connection. I haven't taken a close look at it yet, but unless the compression algorithm has been changed to be more aggressive, this may be a bug. I will be experimenting with a pair of 14.4's and term to see what the performance will be like.

Term is available from ftp://tartarus.uwa.edu.au/pub/oreillym/term.

[4.13] How does one manage a NIS database and the Domain Registry?

I have had several requests for my scripts to merge NIS data into the Domain registry, so I'm making them available. If you don't need them now, contact me when you do need them as I may have made more changes.

[ The first version is available from ftp://ftp.eb.ele.tue.nl/pub/apollo/scripts/NIS+registry. Be sure to contact Mike for an update. -- David K. Ahn ]

It's not as easy as it should be. If you want BSD (lpr/lpd) printing, then see the separate file "printing," available in:

• ftp://archive.umich.edu/pub/apollo/printing
• ftp://ftp.eb.ele.tue.nl/pub/apollo/notes/printing

If you want to use Apollo (prf/prsvr/prmgr) printing, in particular if you want to use a dot-matrix or other unsupported printer, then see the "generic" driver and related comments. These files are available in:

• ftp://maths.su.oz.au/print_driver.README
• ftp://maths.su.oz.au/print_driver.tar.Z
• ftp://ftp.eb.ele.tue.nl/pub/apollo/print/print_driver.README
• ftp://ftp.eb.ele.tue.nl/pub/apollo/print/print_driver.tar.Z

The Apollo lpr/lpd seems to differ from other BSDs in that it apparently references the Domain name (set by ctnode) as well as servername (created in /usr/spool/lpd by the system administrator). Those names should agree with the Internet hostname. The hostname is set by default to the Domain name (which by default is set to the hard disk name, I think, as Yan Lau suggested in his note on how they resolved this problem). IF YOU MODIFY rc.local TO EXPLICITLY SET THE HOSTNAME (IGNORING THE SAGE ADVICE IN THE COMMENTS THERE), THEN LPR/LPD WILL NOT SPAWN NEW DAEMONS. The best solution might be to get the lpr/lpd sources and recompile, but the easiest solution seems to be:

uctnode <your old node name>
lcnode -me (get your node number)
ctnode <internet hostname you want to be> <your node #>

• Then be sure the lines in rc.local that set hostname are commented out so the hostname will be the Domain node name
• Then be sure that /usr/spool/lpd/servername contains the same name as the Domain name (hostname > /usr/spool/lpd/servername)
• Then carefully check the protections on lpr, lpd, and the various spool directories as suggested in earlier notes on this problem.

Of course, look in the BSD Systems Admin guide for other aspects of the setup such as printcap entries, etc. This approach has the advantage that it doesn't require modifying sendmail.cf to handle Internet mail, etc. (the "I refuse to talk to myself" problem that started all of this!).

I have just been through the exercise of setting up (BSD) lpd, to allow BSD-to-prf printing. I hope these notes will help others to do the same.

You need to set up your /etc/hosts.lpd file to allow other hosts to connect to your lpd. Note that contrary to what is said in the file 'printing' referenced in the FAQ, you should not put these names in any /.rhosts or /etc/hosts.equiv files (lpd does its own checking, not using rsh; unless of course you also want to allow rsh/rogin access and live dangerously).

The manuals, and the FAQ file, tell you to create a file /usr/spool/lpd/servername containing the full, expanded TCP/IP name of the node; and maybe even set the AEGIS (ctnode) name of the node to this same name. What I found to work best is to put the AEGIS name of the node in the file /usr/spool/lpd/servername. However, lpd will not start with the file in place (I could not get lpd to tell me why). What I did was modify /etc/rc to have something like:

/bin/rm -f /usr/spool/lpd/servername
/usr/lib/lpd
(echo "$NODENAME" > /usr/spool/lpd/servername)

Then I do not have any of the "cannot start daemon" problems, and do not care that adder.maths.su.oz.au is really //c640g.

I wanted BSD-to-prf printing. My /etc/printcap file is something like:

        # These entries spool files via the prf command (invoked from
        # /usr/lib/lpfilter).  They work for ANY file (ASCII text or
        # postscript), as prf handles them both.
        aolw|Applied Office Apple LaserWriter:\
          :lp=/dev/null:\
          :sd=/usr/spool/lpd/all:\
          :sf:sh:\
          :if=/usr/lib/lpfilter:\
          :lf=/dev/null:\
          :mc#1:sc:\
          :mx#1000:

with (except for the name) identical entries for the other printers. My /usr/lib/lpfilter file contains:

        #!/bin/ksh -
        # Filter to use with lpd: will print file with prf.
        #
        function mess
        # Put message in log file.
        {
        print -R "$(/bin/date) $*: <$USR> <$HST> <$PRT> <$FIL>" >> \
          /usr/adm/lpd.log
        case "$1" in Bad* ) exit 0;; esac
        }
        #
        USR=
        HST=
        FIL=
        PRT=
        #
        while [ $# -gt 1 ]; do
          case "$1" in
            -n ) USR="$2"; shift;;
            -h ) HST="$2"; shift;;
            -J ) FIL="$2"; shift;;
            -p ) PRT="$2"; shift;;
          esac
          shift
        done
        #
        case "$USR" in '' | *[!a-zA-Z0-9._]* ) mess 'Bad username';; esac
        case "$HST" in '' | *[!a-zA-Z0-9._]* ) mess 'Bad hostname';; esac
        case "$PRT" in '' | *[!a-z0-9]* )      mess 'Bad printer' ;; esac
        #
        mess 'Printing'
        /bin/rm -f /tmp/print.u
        /usr/apollo/bin/prf -check -printer "$PRT" -user \
          "$USR@${HST%.maths.su.oz.au}"  /bin/rm -f /tmp/print.u

Hope this will help someone.

I use a cron to run a script as user root on a regular basis to backup the registry. I have been checking the log file recently and every time the following error message appears:

        Unable to go into maintenance state.  User not authorized to
        perform operation (network computing system/Registry Server)

Any ideas?

The registry service is a distributed application that uses an encryption based authentication algorithm. This means that breaking security on a single machine does not allow you to attack the registry database - you have to have access to an administrator's password in order to perform updates on the registry.

One workaround for the problem you are having is to make sure that cron is running as the real "root" user. To do this, don't run cron from the /etc/rc script. Instead, login as root and then run cron in the background (I believe that the command "/etc/server -p /etc/cron" will protect the cron process from termination when root logs out.) Don't forget the "-p" option - this preserves the current user's identity. If you leave this out, cron will run as user.none.none and will not be able to perform its normal tasks.

You need only do this on the machine that is responsible for performing routine backups for the registry database. All other machines can start cron in the normal way.

Future distributed systems will have this behavior for most services. For example, the OSF DCE (Distributed Computing Environment) uses authentication protocols for all distributed accesses (including access to files on non- local machines). Fortunately these systems come with better mechanisms for running batch jobs from cron (unlike the "hack" I describe above).

I always use fixvol to reformat the track the bad spot is on. If you would rather just move the block into the badspot list, here's an excellent description of the problem and fix, from Paul Szabo:

This article describes how to get rid of bad blocks on disks. Bad blocks will naturally develop during the useful life of the disk. There is no cause for alarm as long as the total number or the rate of growth of bad blocks is not excessive.

Once these bad blocks develop, they should be avoided (i.e. should not be used). While the problems are intermittent or recoverable, you may be inclined to put up with the problem. But bad blocks usually deteriorate, and may cause your node to crash. (Our DN10000 developed a bad block in a directory, and any access to this directory sometimes caused it to crash.) Simply, you need to add the block numbers to the bad spot list using INVOL.

If you are happy to wipe the disk and start from scratch, everything is easy. Run EX DEX, RUN WIN (no defaults, all disk: start 0, end last address, write enabled) and this will tell you about every single bad block. Add these to the bad spot list using INVOL, re-format the disk, and install the OS. There is no need to go to this extreme, however.

Get a listing of problem blocks using /systest/ssr_util/lsyserr. You should use this periodically to monitor the behaviour of the disk. Look for repeated problems with disk blocks; you may want to skip the once-only problems. Use the physical disk addresses. (In case of striped disks, ignore the RELATIVE addresses. Run the output of lsyserr through "grep 'Phys daddr =' | sort | uniq -c".) You could also run EX DEX, RUN WIN -ENTIRE. This will read all your disk (without re-formatting or writing it).

You may simply tell INVOL about the bad block addresses, and then run SALVOL to fix up the disk. This seems to work reasonably well, but then ... do you trust them (or any other Apollo utility :-) to work properly? (Note that SALVOL occasionally uses addresses relative to a logical volume, these are one smaller than the physical addresses. Then again, the discrepancy is sometimes not one but two... this may be related to a physical volume PV label on each of our striped disks.)

To give you confidence in what you are doing, you would like to know what files are at those disk addresses.

You may use /systest/ssr_util/rwvol (select READ, enter DADDR, then just [RETURN] for start and end) to display UIDs of objects, then /systest/ssr_util/upath to display pathnames.

Probably it is easier to use /systest/ssr_util/fixvol (this has online help, type help). Use the read command to display UIDs/pathnames:

  (fv [p])> r 12345
     uid:       478771C7.3001A581 /y/sfw/reduce3.3/fasl/int.b
     page:      9
     dtm:       478774A5   Wednesday, December 20, 1989   11:40:12 am (EST)
     blk_type:  0
     sys_type:  0 (file_$file_type)
     pad:       00000000 00000000
     checksum:  0000
     daddr:      12345 ( 163- 1- 0)  disk# 1

Now that you know the pathname, you may wish to move it somewhere 'out of the way' and copy it back to its proper place /bin/mv file /lost+found /bin/cp -pPiov /lost+found/file dir This may not be necessary, but it is cheap insurance.

It seems to me that you cannot do much about vtoce blocks:

  (fv [p])> r 1234
     uid:       202.00000000 vtoc_$uid
     page:      1232
     dtm:       4AF72F18   Wednesday, June 13, 1990   9:53:49 am (EST)
     blk_type:  0
     sys_type:  0 (file_$file_type)
     pad:       00000000 00000000
     checksum:  0000
     daddr:     1234 (  16- 2- C)  disk# 0

BEWARE: if the bad blocks are in the vtoc, then SALVOL may not be able to fix up your disk, in which case you will have to wipe it and start from scratch.

You are now ready to tell INVOL about the bad blocks.

Run SALVOL to fix the disk. SALVOL will find 'multiply allocated blocks' (since they are also in the bad block list), and then go into 'second pass' looking for these multiply allocated blocks. SALVOL will report to fix some objects with the correct names, but for others it will report to repair objects at 'vtocx = something' (when the block is not at the beginning of the file?). It will attempt to copy the bad block somewhere else, and usually it will succeed.

There is one problem with SALVOL. If the bad block is in a directory, SALVOL will orphan the files catalogued there; but as it succeeds in copying the bad block, the files will still be catalogued in the original directory. When you boot the node, find_orphans will catalogue these files in /lost+found, but the reference count (number of hard links) will be wrong (one instead of two). If you remove the file pointed to by /lost+found, then when listing the original directory you get the message 'object not found'. Admittedly, SALVOL at the end of its run said '... errors ... require that Salvol be run again ...' which I did, but that did not seem to do anything. Maybe it needed find_orphans between the two runs. Anyway, I made another copy of the files...

Appendix

The only manual I have on the workings of SALVOL is rather old: 'DOMAIN System Utilities', part no. 009414 Rev 00, Sept 1986. Some quotes from this manual below. (The newer 'Domain Hardware Utilities Reference', part no. 014881-A00, barely describes how to use SALVOL.)

Classes of errors: ... 4. Multiply allocated blocks... allocated to more than one file, or to a file and to a system structure, such as the VTOC, the BAT or the badspot list....

The salvager attempts to repair multiply allocated blocks... if the salvager finds a multiply allocated block and can determine which file the block belongs to, then it sets the trouble flag only for the non-owning file.

DOMAIN disk volumes are structured so that naming directories and space/location information (in a VTOC) about files are kept separately. Currently, the salvager does not synchronize these on-disk structures. ... cannot detect orphans...

I/O errors that occur on physical and logical volume labels or on the block availability table (BAT) are fatal to the salvager. All other errors are reported, but are non-fatal.

Generally, the salvager always repairs the BAT (except in the case of hard I/O errors) and the VTOC. Thus, if AEGIS badly malfunctions, writing normal file blocks over the BAT or the VTOC blocks, for example, the salvager repairs the BAT or VTOC and the file. To do so, it copies the data into a newly allocated block and reinitializes the overwritten block.

If a block is multiply allocated to both the badspot list and to a file or a VTOC chain, the salvager tries to copy any potentially valid data to a newly allocated block. If the block is in the badspot list because of persistent device level errors, however, the copy may fail; the salvager then prompts for alternatives. The salvager and badspot listing cannot be used to correct persistent errors in the BAT or VTOC hash space, however. The salvager aborts in the former case, and simply reports the I/O error in the second case. The only solution is to reinitialize the volume around such badspots using INVOL.

A company called MicroMechanics in Cambridge, MA, has acquired the rights to manufacture, distribute, and support the PC coprocessor (DPPC), the PC emulator (DPCE), and the PC integration (DPCI) products for Domain/OS. The founders were involved in the initial DPCC development. For further information, contact:

        MicroMechanics
        84 Sherman Street
        Cambridge, MA  02140
        Tel. (617) 868-1899 FAX
        (617) 876-5950
        Net: umech!ljohnson@uunet.uu.net

>Another "opportunity for excellence" awaits.  I am currently experiencing
>problems with the "preserve" function.  Whenever I reboot a workstation
>(OS 10.3.5.4 and 10.4) and there are files to be preserved (so to speak)
>the machine "hangs" at the "Preserving Editor Files" message.  I usually
>have to crash the machine, set to service mode, salvage, get to Phase II
>and delete files in tmp and /usr/preserve directories before bringing the
>machine up.  I figure this is a permission problem of some sort, but how
>do I fix.  I did not see this in the FAQ.

This is another result of Domain/OS not being real UNIX--preserve is trying to mail each user who has ed/ex/vi files left a notice of what was left at the time of the crash and how to recover it. However, neither the registry nor tcp is available, so sendmail hangs trying to deliver the mail, which hangs your boot since the preserve waits for its children to complete (so /tmp can be cleaned safely). Your solution is the only way out once it happens; I have disabled the 'preserve' step in /etc/rc so it doesn't get stuck there (just comment it off). Another solution would be to do the preserve later (and the /tmp cleaning too), but then you must be quite careful about what is deleted, as some files belonging to boot processes will probably exist by that point.

If you run prmgr/prsvr/prf to PostScript printers and want to know who is printing how many pages, then this is for you.

My audit_filter package is available from ftp://maths.su.oz.au/print (129.78.68.2), and ftp://ftp.eb.ele.tue.nl/pub/apollo/print/audit_filter.tar.Z .

The file audit_filter.README is included below, as well as the README file for the generic printer driver which is available from the same sites.

Audit filter, version 1.0, dated 14 Sep 93

audit.c is an audit filter. It is for use with the Apollo prf/prsvr/prmgr with the postscript printer driver, and is compatible with SR10.4 only. It shows the number of pages printed in each job, and aids somewhat in detecting attempts to avoid accounting.

To compile/install the filter simply execute the INSTALL script.

Suggestions are welcome. For further information, please contact the author: (Standard copyright and disclaimers apply.)

Use xntp, available from the usual ftp sites. See the file Readme.xntp for Apollo patches. See date.tar.Z for a simple program that just sets one node's clock from another node's clock.

[Note: these files are on Jim Rees' archive: apollo.archive.umich.edu ]

Timed works well on SR10.2-nodes (it did not work in SR10.1).

We start it from rc.local as follows:

and we list this local network in /etc/networks. This works well for synchronizing the clocks among all Apollos in the local network.

Recently, we wanted to synchronize the clocks with the outside world also (i.e. other workstations in our department). Our Apollos are connected through a token ring, but one of them has an Ethernet card and runs routed to provide the connection to the outside world. On this machine we do the following:

The other ones still listen only to the local network, and do not attempt to become master anymore:

This implies that when booting our Apollos the "master machine" must go first. Timed only accepts corrections from the timed on another machine if they are not "too extreme". In the latter case set the clocks manually using /bin/date once before starting the time daemons. If you set a clock backwards, don't do it with /bin/date, but shut the node down, use:

You may be interested in the "-a" option added to sr10.4 timed. It specifies that the master rules the network, with no democratic input from the other nodes, and thus it's irrelevant when it boots.

If you're experiencing problems starting the master rgyd or creating a registry database, the following information should help.

There are a few things that must happen for the node to see your master registry. You MUST have a local location broker daemon running. You will either have an llbd or rpcd running as your local location broker. Since this node was brought into your domain, and I assume you did not re-build it, you must copy the "glb_obj.txt" file from your MASTER GLOBAL LOCATION BROKER node. Kill your llbd or rpcd process on your new node. To find your master glbd, run the "drm_admin" command on another node. Do a man page to get command info. The glb_obj.txt file is located in the /etc/ncs directory. Copy it to your new node in the same location. Make sure that a stub exists in the /etc/daemons directory to start the rpcd or llbd process. Now, this is a trick I got from the HP HOTLINE. Delete the file "/sys/node_data/etc/.rgyloc" and rename "/sys/node_data/hint_file" to "/sys/node_data/hint_file.old". Shut the node down and reboot. The system should come up seeing your master registry and print manager. Also, remember to update your root directories on ALL nodes "ctnode -update". The master registry node must know about the new node's "name" either it be //node_HEXCODE or //"name", AND the new node must know about the other nodes as well. **Make sure you do this BEFORE you reboot the node.**

You should do some tests: Look in /sys/node_data and check if the files glb. ... exist. Then you should check if the rgy is working: start '/etc/rgy_admin' see the result and type 'lrep -st' at the rgy_admin prompt. If all works fine you should see something like

        #  /etc/rgy_admin
        Default object: rgy  default host: dds://chh
                State: in service  master  replica list is writable
                rgy_admin: lrep -state
                (master)  dds://chh    state: in service   1994/06/11.14:28:35

If you see another result the registry is not working correct. If the default host is not specified you could do it. See the on-line help. If you see something like 'registry service unavailable' then you your rgyd is not working properly. Stop the rgyd if it is running and restart with the option 'recreate'. Try also with edrgy to add a new user. You can add one only if all works correct. Next you start '/etc/ncs/lb_admin. An Domain Dialog interface is opened grow the pad until you see all of it. Look at the grey field middle-top. Click local or global broker with the left mouse key, click 'clean' and 'lookup' to see if the broker has really registerd you registry etc. (BTW you need to work with this tool if for one reason or other your network printer is not recognized.) If your registry is not registered then your setup/start of the daemons was wrwong or failed. Exit by clicking on 'Exit'. Now you 'cd' to /sys/node_data/system_logs. Copy 'glb_log' to 'xxx', the file is in use, you cannot read it if glbd is running, See if you have a content like

        (DRM) 1994/06/01.14:52:16  opening replica.
        (DRM) 1994/06/01.14:52:31  replica of object glb opened.
        (DRM) 1994/06/03.11:36:53  opening replica.
        (DRM) 1994/06/03.11:37:10  replica of object glb opened.

If you see errors like

        (DRM) 1994/02/25.14:59:04  [1c010001] unable to open replica of object
        glb.
        ?(GLB) cannot open replica - communications failure (network computing
        system/RP C runtime)
        (GLB) exiting

then your global broker does not properly work. (Don't forget to rm 'xxx'.) Therefore you start '/etc/ncs/drm_admin'. If you get the drm-admin prompt type 'set -o glb -h //'. You should see something like

        Default object: glb  default host: //chh  state: in service
                Checking clocks of glb replicas
                        dds://chh               1994/06/13.11:57

You see the managment of NCS is somewhat intricate. I suggest that you first try to isolate what is going wrong. If you do have a fresh registry i.e you have not added a lot of users the best is to start from scratch. Also check the ACls of /etc. I had curious results in the ACls after different installations of 10.1 - 10.4 ( which could be reproduced by the German HP staff. *also* until 10.3 there was a bug in updating the /etc/passwd file. ) If you dont have the admin manuals you can run into problems. So try first and if you get the registry not running you can mail direct or call me up.

One extra point : If you try around and you once get a message saying that the registry is not writable, then use in 'rgy_admin' the option state -in_maintenance | -not_in_maintenance to put it to work. You use this option also before making a backup of the /sys/registry tree.

One of our systems here crashed and came back up with the error message:

        Returned status (from pm_$init): F0005

after the copyright message and starting all the daemons, etc. LTX begin the useful people they are suggested reinstalling the OS (this is a production system, not to mention rgyd, glbd, prmgr master server). Not a pleasant prospect. I decided to try a few things first. I removed /etc/ttys and rebooted which brought the system up but without DM so it was running but with no way to log in. That allowed me to connect from another system and mess around. I replaced /sys/dm and /sys/spm and /etc/dm_or_spm and removed and recreated everything in /dev. And when I rebooted everything worked. So I can't limit it to one particular thing (I was under time pressure and couldn't afford structured problem solving time) but I though if anyone else ran into this problem, they would appreciate the info.

The status code F0005 (see above) means:

        object is not locked by this process (OS/File server).

This would tend to mean that some file that the node is trying to use when starting a new process is still locked by another process, possibly a zombie. Since you don't know which fix did the trick, it is difficult to say what the original problem was. If it happens again, I would suggest booting the node diskless from another node, and using llkob to check the list of locked objects, after mounting the local disk as a mounted volume. Anything that is not remote must be junk, in that mode. The ulkob -f command can sometimes free up such locked objects. If the /dev fix is what did it, great. /dev is easy to rebuild. If the /sys/dm was the problem, I would think that the protected subsystem acl's might have become corrupt. I had that problem a few times, but with different symptoms. Do check the protected subsystems, as you were mucking around with dm and spm.

I've occasionally encountered the error message:

        Returned status (from pm_$init): ok

when an Apollo boots up and loads the global libraries. I've found two reasons why this happens. The first is that part of your global libraries are either corrupt or missing (the files in /lib). The second reason is that some configuration file in /sys/node_data are corrupt or missing. The most prominent example of this second reason is an incorrect syntax in the /etc/rc file. To correct the first problem, you'd have to copy the /lib/* files from another node or reinstall the OS. To correct the second problem, simply create a single user shell and edit the broken files.

Another nasty reason for "Returned status (from pm_$init): ok" is a corrupted or missing /dev/null (eg it might be "unstruct" instead of "null). You can't get to a single user shell to fix this, but you can do it from Phase 2:

    ) wd /dev
    ) wd ..
    ) chn dev dev.bad
    ) cpt
        source:      /sys/sysdev
        destination: dev
        options:     r
    ) shut

Reboot - you are running on a criplled /dev/ so some things might fail, but you should now be able to mkdev a proper /dev directory.

To break into a Domain/OS system, you can follow this procedure:

• Place the node into service mode
• Boot the node using:

      > DI W
      > EX DOMAIN_OS
  

• When you get to the ) prompt, do:

      )wd /sys/registry
      )chn rgy_local rgy_local.bak
      )dlf /etc/daemons/rgyd
  

• Now your registry is empty. Boot the machine using

      )go
  

• Login as user at the login prompt. If hitting enter for the password does not work, try "-apollo-".
• If you want to, you can leave your system like this, most functions are easily accessible by user. If you want to setup a real registry, you can do:

     $ /install/tools/rgy_create
     $ touch /etc/daemons/rgyd
     $ touch /etc/daemons/glbd
     $ touch /etc/daemons/rpcd        [ or llbd for OS under SR10.4 ]
  
     $ /etc/server /etc/ncs/rpcd
     $ /etc/server /etc/ncs/glbd -first -create -family dds -listen dds
     $ /etc/server /etc/rgyd
  

  Now you can reboot the machine and login as root with password "-apollo-". You could put in the DDS-only options to your registry daemons so they will always use DDS for transport by putting
  • "-listen dds" as a parameter to /etc/ncs/glbd in /etc/rc; and
  • "ncadg_dds" as a parameter to /etc/ncs/rpcd in /etc/rc

Some of the information on setting up the registry was borrowed from an article by Paul Szabo (szabo_p@maths.su.oz.au) on how to install Domain/OS from tape (from-tape.txt in the UMich Apollo Archive).

How to break Aegis and Domain/IX registries (SR9):

If your machine runs Aegis without Domain/IX, you do not have any root accounts. You can login as user and do almost anything. SR9 had no protection modes whatsoever (almost). If logging in as user does not work, boot the machine in service mode, and do:

    )wd /registry
    )chn rgy_master rgy_master.bak
    )chn registry registry.bak
    )chn local_registry local_registry.bak

Now you have an empty regisry. To initialize a registry, follow these procedures (from "Administering Your Domain System", SR9 style):

• Login as user
• Now initialize the registry directory (/registry).

      $ /install/init_master_rgy
  

• Add users using edppo/edacct in command line mode:

      $ edppo -a name [fullname]
      $ edppo -proj -a project_name
      $ edppo -org -a organization_name
      $ edacct -a pers proj org homedir password
  

  Or, using interactive mode:

      $ edppo
      => ...
      => wr
      $ edppo -proj
      => ...
      => wr
      $ edppo -org
      => ...
      => wr
      $ edacct
      => ...
      => wr
  

Around April First of this year reports started circulating in the Apollo Usenet newsgroup of a "date bug" in Domain/OS that would render all Apollo workstations useless after November 2, 1997. Given the proximity to April Fool's Day and recent horror stories involving the "Millenium Bug" (software unable to cope with dates in the 21st century and costing billions of dollars to fix), most people dismissed these reports as a hoax.

Unfortunately the reports were at least partly true. One user has reported that setting the clock past November 1997 and trying to boot fails with "UNABLE TO MAP `NODE_DATA/STACK -- 40001."

The bug apparently results from the high 32 bits of the clock data type being declared as a 31 bit value instead of 32 bit in the pascal include files. The reason for this is lost to history, but early pascal compilers may have had problems with 32 bit unsigned numbers, possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations.

The bug will cause problems when the high bit (not the "penultimate bit," as the patch description says) becomes set at 14:59 GMT on November 2, 1997.

A letter from HP to customers on maintenance contracts said that, "The 9601 Domain patch kit... repair[s] a timer defect which caused the system to malfunction in a variety of ways after November 2, 1997."

A search on the HP Supportline web server (free to all, not just customers on support contracts) turns up 11 patches related to 1997. After stripping out the duplications for various versions of Domain/OS, the problem software seems to be domain_os, /lib/kslib, and the d3m, mbx, and alarm servers.

Although the letter from HP says "each patch bundle... is supported on all SAU types," the patch does not include a domain_os for any machine type below sau7 or for any version of domain_os before sr10.3.5, so the fix is not available for any Apollo node released before the dn3000 or for those still running sr9.7.

One possible solution for users of older machines or software would be to set the clock back to a date before November 1997. Other than the obvious problems of having wrong date stamps on everything from file modification attributes to email headers, there are two potentially serious problems with this. One is that if you have two nodes on your network with serious time skew between them, some network protocols will not work. The other is that you will run the risk of getting duplicate file uids, which may result in file system corruption.

If you do get the 1997 patch, or any other patch, from the HP Supportline web site, you should be aware of a couple of problems.

First, what you get isn't the patch itself, it's a uuencoded compressed wbak file with a lame uudecoder tacked to the front. So you'll first have to trim the garbage, then uudecode, then uncompress. None of this is mentioned on the page that describes the patch.

Also, the "rbak" command given is wrong. The correct command is:

One user reports that using the "rbak" command given by HP left his node unbootable.

As November 1997 approaches, those of us with older Apollo nodes will be faced with the unpleasant choice of either taking the risk of setting the clock back, or sending our equipment to the scrap dealer. HP has so far not shown any interest in helping us with this choice.

They managed to release a bad patch: installing it, cal_$encode_time or similar fails in any September, or on the 5th of any month, or at 6am of any day...

As has been reported by psz@maths.usyd.edu.au and tomb@badgers.demon.co.uk, the Domain/OS patches to fix the 11/2/97 problem broke cal_$encode_time for many dates, including the 5th of every month. I've seen no HP fix yet.

The problem does not seem to affect much system software; the only case I found was where e.g. "/com/ld -moa 90/8/5.10:00" finds no files due to the bug. Nevertheless, I offer the following 1-byte patch for those brave enough to patch system code. Caution: proceed at your own risk, and be absolutely sure you are patching the same version as me.

File: /lib/kslib (from pd96_m0739) 122,244 bytes Timestamp=12/12/95 (Note the timestamp does not match that given in the 9601 document.) Procedure: (# and ! are prompts, () enclose comments)

  # cd /lib
  # cp kslib kslib.patch
  # /com/db
  ! ma kslib.patch
  1DD84 bytes mapped at XXX
  ! ab XXX+0CFD1               (Where XXX is where it mapped)
  (db prints:) 8 (and leaves cursor there. Enter:) 54 / <Return>
  ! q
  # mv kslib kslib.orig
  # mv kslib.patch kslib
  (reboot)

Explanation: In the kslib released with SR10.4.1, cal_$encode_time returned an error value (fff7ffff ffff) for any year > 2013. Patch pd96_m0739 fixes cal_$sub_clock to work with unsigned instead of signed values, to fix a problem after 11/2/97. But for some reason the patch also includes a "fix" to cal_$encode_time. The fix tries to squeeze out more valid dates by making dates up to 9/5/2015.05:58:26 valid. But the logic is wrong. The check for (year >= 2015) is independent of the checks against the month and day. The code in pd96_m0739 probably looks something like this:

    if (year > 2015) ERROR
    if (year == 2015 && month > 9) ERROR
    if (month == 9 && day > 5) ERROR
    if (day == 5 && hour >= 5) ERROR
    ...

After applying the above 1-byte patch, the logic looks like this:

    if (year > 2015) ERROR
    if (year == 2015) {         <<= This is the branch offset I changed
      if (month > 9) ERROR
      ...
    }

[5.0] SYSTEM RELATED HARDWARE

If you have a DN2500 or the HP9000/4xx boxes, you can add SCSI-1 by simply connecting them to the on-board SCSI port, assigning the a legal device ID and terminating the chain. This is fairly straightforward. The 9000/4xx series can have up to about 9GB of SCSI disk space.

[ Maintainer's note: This is not exactly true. See below. ]

There are several restrictions to adding more disks to a DN[345]xxx box. If you have an SMS/Omti (8xxx, 11914 model) ESDI floppy/hard drive controller card, then you can add only up to two disks per node. The disk type must be ESDI, not SCSI, SCSI-2, MFM, IDE, etc. The only models which Domain/OS supports are a few 76MB disks (Micropolis, ?), Micropolis 1355 170MB, Maxtor 4380 380MB and the Maxtor XT-4380E 380MB Fast Actuator disk. You cannot use the Maxtor XT-8760E 760MB disk with the SMS/Omti controllers. I do not believe Domain/OS supports any other disk types, although there may be a few other drives that work. Contrary to Apollo's claims, you _can_ mix drive types when hanging two disks off of one controller. That is, you can have a 170MB and a 380MB disk. There have been some claims that one or both of these disks must be "Fast Actuators," but this is not true with the SMS/Omti 11914 controllers. Note: it is very important to check your SMS/Omti's ROM revision; some of the older ones (revision B or less?) do NOT support the 380MB disks. In addition, when replacing or adding a second disk, you must make the proper jumper settings (see /ssr_util/systest/jumper).

If you have a WD7000V-ASE controller card on you DN[345]500, you are in luck. The WD supports both the ESDI and SCSI storage interfaces simultaneously (although you can disable one or the other). The ESDI interface supports all disks that the SMS/Omti's support, in addition to the Maxtor 8760E. The WD has the abillity to automatically "recognize" what disk is connected, so no jumper settings for different disks are required. Furthermore, you can have two WD's in one node, expanding the total maximum ESDI disks capacity to over 2GB [if you do this, the second controller _MUST_ have its SCSI interface disabled]. If you have SR10.4.0.xx or below, the SCSI interfance can only be used with up to 7 non-disk storage devices, including CD-ROM, 4mm, 8mm, QIC, 9 track, optical, etc. If you have a non-SCSI tape/floppy already, you cannot use the SCSI interface of the WD, so it _must_ be disabled. If you have SR10.4.1 or above, the SCSI interface can also be used with hard disks (see below).

The 8mm tape drives must be SCSI ids 1,2,3, or 4. These correspond to devices rmts8, 9, 10, and 11 (12-14 for non-rewinding devices). Although wbak is not officially supported on 8mm drives, it works fine at 10.3+ (and at 10.2?). Use m0 for SCSI id 1, m1 for SCSI id 2, etc. There is a long pause before it starts writing the tape with wbak. The tar and omniback packages work just fine (as do lots of other vendors' backup packages, I'm sure).

Domain/OS SR10.4.1 now supports SCSI disks (in addition to other SCSI non-disk peripherals) on DNxxxx nodes with WD7000 controllers. From the release notes:

SCSI hard disks are now supported on DN3500, DN4500, DN5500, and DN100x0 running Domain OS SR10.4.1. ... The supported SCSI disks are:

• C2217T Series 6000 Model 1350SE
• C2474T 1.3 Gbyte upgrade for the C2217T tower

[Note: I would assume that most SCSI disks will work without problems. If there are known incompatibilities, please let me know, and I will include the info in the FAQ]

SCSI hard disks are supported through an external connection to the Western Digital WD7000-ASC controller card. SCSI hard disks can be used only in conjunction with a primary or boot ESDI hard disk and not as the primary or boot disk.

The invol and salvol programs initializes the disk and are executed on the SCSI hard disks after the OS is running. The stand-alone sau utilities, invol, salvol, etc., do not support the SCSI hard disks.

Volume striping is supported across the SCSI disks. The maximum volume size is 2GB on the DN3500 and DN4500, and 4GB on the DN5500.

The SCSI disks are accessed by invol, salvol, mtvol, etc., with the names w2:0, w3:0, ..., w6:0 on the DN3500, DN4500, and DN5500; and with the names w4:0, w5:0 and w6:0 on the DN100x0.

Apollos don't like to be hooked up to a SCSI-2 drive!

> These drives will work with 400's (and DN-2500's) if they are set to
> respond as SCSI-1 or SCSI-1/CCS devices. You need to execute the Change
> Definition SCSI command on the drive to change their response. Talk to
> your supplier and see if they will do this for you. (R Squared does this
> sort of thing all the time, besides (normally) providing manuals :-)

If you have a SCSI-2 drive that you want to put on a DN-2500 or HP/Apollo 9000/4xx system, and if INVOL doesn't like it (device xyz not recognized by device driver), then the "mts" program may be used to execute the Change Definition command for those drives that do not have jumpers to perform this function. The mts program is available from the IWorks library system archives, and the specific option is accessed through the "debug" command.

We are currently installing a DEC 5200 2 Gb disk which was SCSI-2 Using mts got us atleast as far as running invol on it. Took quite a while to get the baby formated, though. Only wonder is whether the change command is permanent?

Try using /systest/ssr_util/scsi_info to check what info is returned from the drive. It probably claims to a a SCSI-2 device ... in which case the Domain/OS SCSI disk software is going to refuse to deal with the drive. Many disks can be configured as either SCSI-1 or SCSI-2 depending on their jumper settings.

Yes, you can use Exabyte SCSI-1 EXB-8200 tape unit with the Apollo, provided your Apollo has an SCSI interface (built-in or with WD7000V-ASE). There is no need to create a device file, like /dev/exabyte, using the /etc/mknod command. The device files already exist:

        id  devices         wbak/rbak -dev
         1  rmts8,  rmts12    m0 (default)
         2  rmts9,  rmts13    m1
         3  rmts10, rmts14    m2
         4  rmts11, rmts15    m3

It is recommended that you rewind the tape before accessing it with:

There are some problems with using the 8200 SX drives because of the length of time it took to rewind, label, reposition, etc. A wbak label of the tape fails. The 8200SX works with tar at SR10.4, but rwmt does not.

Apollo's earlier tape utilities, including "wbak", "rbak", and "rwmt" access the tape drive directly via calls to either the magtape driver or the cartridge tape driver, depending on whether you use "-dev mt" (the default) or "-dev ct". These calls are made via the unreleased "tfp_$" calls, which then branch out to either the unreleased "mt_$" or the "ct_$" calls. All of these library routines are in /lib/tfp. When Apollo introduced their 8mm Exabyte drive, they wrote a new tape library to support the drive; and they did *not* add support for the drive to the existing "tfp_$" library. Thus, the older Apollo programs can not access Apollo's 8mm drive. Only programs which use the new tape library can access the drive, and Omniback is the only Apollo utility that I'm aware of which does use the new library.

The standard Unix utilities, such as "tar", "dd", "mt" and the like, all access the tape drive via a Unix device file (eg. /dev/rmt0). As of SR10.x, Apollo has supplied device files for SCSI tape drives attached to either the native SCSI port of the DN2500 or the SCSI port of the multi-function WD7000 disk controller used on most DN3500 and DN4500 machines. These device files are /dev/rmts8 and /dev/rmts12 (rewind and no-rewind) for SCSI tape device 0, and /dev/rmts9 and /dev/rmts13 (rewind and no-rewind) for SCSI tape device 1 [note: hardware hackers, feel free to correct me! this explanation is getting long enough to publish as an article -- I'd *hate* to get this wrong in print!!]. These device files invoke the *new* Apollo tape library, and therefore can access the 8mm Exabyte drive in addition to SCSI cartridge tapes and SCSI 9-track tapes. The device files /dev/rmt8 and /dev/rmt12, on the other hand, access the old tape library for 9-track drives; and /dev/rct8 and /dev/rct12 access the old tape library for non-SCSI cartridge tape drives.

Now, there *is* a way to use "wbak" and "rbak" with the 8mm Exabyte drive: you use the "wbak -to" and "rbak -from" options to redirect I/O to a file instead of old tape library, and you use either /dev/rmts8 or /dev/rmts12 as the file name. There is a minor drawback to this: the ANSI labeled tape options such as "-fid" (file ID), "-vid" (volume ID), and "-f NN" (write to the NNth file on the tape) won't work -- you can only write an unlabled file to the current position on the tape.

So much for HP/Apollo ... There *is* at least one 3rd party vendor that provides a cleaner solution. Workstation Solutions sells the Exabyte drive packaged with a version of the *old* Apollo tape library that supports the 8mm drive, and a utility program that automatically loads this library prior to running "wbak", "rbak", "rwmt", and any other program you like. The library replaces the regular Apollo 9-track tape library and makes the Exabyte drive look like the 9-track tape. Thus any program which uses the "mts_$" and "ios_$" calls to access a 9-track tape will work ... and any program which uses the /dev/rmt8 or /dev/rmt12 device files (which in turn, access the old Apollo tape library) will also work.

Either way, your Apollo sales person is mis-informed. Exabyte drives *can* be used on the Apollos under SR10 with DN2500/3500/4500 machines via the SCSI tape device files; or under either SR9.7 or SR10 via either the magtape library calls or the old, non-SCSI, device files with Workstation Solutions' package on DN2500/3500/4500 with SCSI ports, or on DN3000/4000 machines with an AT-BUS SCSI adaptor card.

MDL Corp. now has a driver for using Exabyte 8500's, 8200's, 8205's, etc. under DomainOS 10.3.x and 10.4 with wbak, rbak, tar, etc., and supports different densities, etc. as well as automatic byte-swap detection and conversion on the fly for ANSI-labeled volumes (such as those made by wbak).

There exists a video8 backup-unit with a capacity of 2.2 Giga. The name of the company who sold it was Cyber.. Data Group (don't kill me if the name`s wrong, I can look it up if you're realy interested). We used it on a 425 with SCSI.

We used wbak/rbak. Note that there is a problem with wbak under SR10. You can no longer overwrite a file-container > 1 without first overwriting all previous file-containers.

APOLLO supports the new QIC 24 Tape Format only. Sun supports the (obsolete) QIC 11 (default) and QIC 24 formats. Some older Suns do not support QIC 24.

If you write tar tapes on a Sun please use the QIC 24 format. This corresponds to the Sun nrst8-11 devices, for instance the /dev/nrst8. For more information, you may try 'man 4 intro' and 'man 4s st' on your Sun.

Then the archive can be read with the Apollo /dev/rct12 device.

Newer suns support still another (higher density) QIC 150 format. However they still support QIC24, which is the only format supported on the Apollo.

Apollo 1/4" tapes are written as QIC-24 format (60 Mb per DC600A cartridge, ~45 Mb per DC300XLP cartridge). Sun-3's can read and write either QIC-11 or QIC-24 tapes. Sun-4's (Sparcstations) can *read* QIC-24 tapes, but only write QIC-120 (or is it QIC-150?) tapes. Apollo "tar" tapes are readable on Suns, but with pre-SR10 tapes you may need to force the blocksize (if I can remember back to SR9, I think the Apollos were using a blocking factor of 1?) to match.

I currently run SunOS 4.1.2 and SR 10.2.1. I rsh to the target machine and run a csh script similar to the following:

        on intr error
        rm latest_backup_listing
        (/com/wbak -stdout -full -l /whatever | rsh dump_machine \
                dd of=/dev/nrst8 ibs=8192 obs=8192) >&! latest_backup_listing
        if ($status > 0) then
                rsh dump_machine touch ERROR.rdump.target_system
        endif
        exit
        error:
        rsh dump_machine touch ERROR.rdump.target_system
        exit

although I have also tried (and my scripts optioally allow) the following:

        rsh dump_machine "/com/wbak -stdout -full -l /whatever" | \
                dd of=/dev/nrst8 ibs=8192 obs=8192

I have just completed a rather extensive backup package, written in Perl, which may be used to backup Sun, Apollo, and SGI machines, and which features an automated interactive restore facility. I would be willing to make these available to you if you want to try them out.

You can use them, but only with SR10.3.5 (= SR10.3 + PSKQ3_91); you can use wbak/rbak, or tar, or whatever.

We got our DAT drive recently. /systest/ssr_util/scsi_info tells me it is a Sony SDT-1020; the salesman sold it as a Sony 2GB drive. (It is a Sony drive, packaged locally into a cabinet with a power supply.)

I tested the drive with 425t, DN2500, DN10000, DN3500; I cannot remember if I tested it or not on DN4500 and DN5500 (the DN[3-5]xxx with Western Digital controller, Apollo part number 12283; the DN10000 with the SCSI cartridge controller, Apollo part number 12171). It worked without a hitch, as described in /install/doc/apollo/pskq3_91.v.10.3__notes.

This information is available by anonymous FTP at:

The solution is the new Ethernet board (part no. A1658-66016, rev. F), plus the OS/TCP patches from the 9109 or later patch tape. Note that there is a second set of patches that are not on the 9109 tape, which you will definitely need, and even those still have a problem with the "mbuf"s being either all filled or not release properly (we are now having tcpd aborting when it improperly frees a buffer). This is still under investigation by HP (call # A2055392).

There is a SERVICE NOTE on the +5 V portion of the 10k power supplies dated 18 June 1990. A summary of the text follows:

DN100X0/DSP100X0 Serial Numbers: All

Date Code: All +5 Volt Booster Modules with 1988 Date Codes Performed By: HP/Apollo Qualified Service Personnel Only Parts Required: +5 Volt, 150W Control Module (APN 010524-001)

Situation: A problem has been identified with the DN100X0/DSP100X0 power systems in both Manufacturing and the Field. The power system shuts down due to a +5 Volt OV (Over Voltage) failure.

Having evaluated several Power EuroCards from Manufacturing and returns from the field, R&D has identified an oscillation on some of the +5 Volt Booster DC/DC Converters. This oscillation forces the +5V output voltage to exceed +5.3V dc and the microprocessor shuts down the power system.

After having tested different +5 Volt Booster Module configurations, R&D has concluded that Booster Modules with 1988 Datecodes are the direct cause of the +5 Volt OV (overvoltage failures).

Chances are, your card is a general purpose memory board, not a page mode memory board. The DN4500 and DN5500 have a redesigned memory system (interleaved) which requires memory boards to be added in matching pairs (two 4MB or two 8MB boards, but not one 4MB and one 8MB). Here is the memory compatibility table from the manual "Installing Memory in the Domain Personal Workstations and Servers," Order No. D-10615-0:

                                              DS5500-.
                                DS3550,DS4500-.      |
                                DS4000-.      |      |
  DS3010A,DS3500(Except DS3550)-.      |      |      |
  DS3000(Except DS3010A)-.      |      |      |      |
                         |      |      |      |      |
    Size    Part No.     V      V      V      V      V
  --------------------------------------------------------
   2MB(1)   008496       +
   4MB(1)   011982              +
   4MB(1)   013079              +
   4MB(1)   010275                     +
   4MB(2)   013495              +             +
   4MB(2)   013480              +             +      +
   8MB(1)   009988                     +
   8MB(1)   011983              +
   8MB(1)   013078              +
   8MB(2)   013496              +             +
   8MB(2)   013481              +             +      +
  16MB(2) A1918-60001                                +

  (1) General Purpose Memory
  (2) Page Mode Memory

Contrary to belief, the DN4000 does NOT have an interleaved memory system, so you can mix and match boards. Although the above table lists the "official" memory boards supported on various platforms, personal experience has proved that any 4/8MB board which works in the DN4500 will also work in the DN3500 and DN4000. Be careful when you use DN3500/4000 memory boards in a DN4500. I've seen the boards work fine for a few days, even up to a week, then result in a memory parity error and a systems crash.

  Apollo 1 to 3 serial connector:
         Sio 1               Sio 2               Sio 3
        1  -  1             1  -  1             1  -  1
        7  -  7             7  -  7             7  -  7
        2  -  2             2  - 12             2  - 21
        3  -  3             3  - 13             3  -  9
        4  -  4             4  - 14             4  - 23
        5  -  5             5  - 15             5  - 10
        8  -  8             8  - 16             8  - 25
       20  - 20            20  - 18            20  - 19

The left columns are the connections to the divided stream. The right columns indicate the connection made in the joined connector which goes in the Apollo's back.

You can add serial ports with an SPE (Serial and Parallel Expansion) card and the SPE software. The SPE card is actually just your standard IBM-PC serial/parallel I/O card; chances are, you can salvage one from an old PC and use it in the Apollo. You do, however, still need the SPE software (actually just a bunch of drivers and device files) to use the card. At least version 2.2 of SPE is REQUIRED for SR10.4; earlier versions of SPE will work with SR10.1-3.

Apollo warns of input overrun errors when using the SPE ports at speeds above 4800 baud. There is insufficient buffering on the card to support these higher speeds, and you may loose data if the node is loaded. Faster nodes should have fewer problems, but your mileage will vary. Consult the release notes that come with the SPE software. This input overrun problem IS NOT THE SAME as the buffer overrun problems with the SIO ports under SR10.4 The latter problem can be solved by applying a patch.

Philip D. Pokorny has been able to get a STANDARD IBM-PC internal modem to work in a DN3000. The SPE software is required to access the modem. The modem must be configured at address 3f8, COM1, and interrupt 4, and can be accessed thru the use of 'spe_tty_sio1_ddf.' The SPE software installation will create TWO serial device descriptions in /dev/global_devices, so you need to DELETE the one for SPE SIO2; this device does not exist on your modem. Failing to do this will result in an error message at boot time, stating that it was unable to initialize the second serial device. In essence, what you're doing is fooling the Apollo into thinking that the internal modem is an SPE card. Note that the same buffer overrun problems exist with using the internal modem, so you may not be able to use a high-speed (>9600 baud) modem.

As you may have guessed, the Apollo DN[345]xxx boxes have an AT bus. Some of the boards used in the Apollo are bastardized PC cards (such as the disk controllers, SPE card, 1280x1024 video card, etc; see section on SALVAGING APOLLO PARTS for more info). This, however, does not mean you can take any PC card and expect the Apollo to recognize it, even if the card "fits." It is quite possible to write a device driver for a PC card using the Apollo GPIO calls; if anyone writes one for the Sound Blaster, please let me know! :)

Whether or not PC ISA cards can be used in an Apollo depends. Usually, the answer is no. Most of the Apollo cards were designed specifically for the Apollo, so they would be useless in PC's. Likewise, most PC hardware isn't designed to be used in an Apollo, so while the card may fit and the Apollo may boot fine, it won't be able to use it. There are certain exceptions to this. For example, you can take a PC 3C505 16 bit ethernet card and use it in an Apollo (without the boot PROM), and the same goes for a serial/parallel I/O card or an internal modem.

Theoretically, you can write drivers using GPIO routines so that the Apollo can use the PC cards. However, I don't know of anyone who has done this. See below for some info on GPIO, drivers and PC cards.

Writing device drivers with GPIO is pretty easy. The only problem is that usually, non-trivial PC cards use on-card BIOS routines to hide the actual IO going on. Since Apollos have a different CPU, and none of the other PC assumptions hold either, the BIOS isn't much use. And ususally only these BIOS routines are documented; the port IO isn't.

It took me several months to write a VGA device driver, only about two days of which were actually writing the driver code. The rest was just figuring out the blasted barely-documented port IO.

So before you buy a card, check the available documentation.

Actually, the ATR card used in Snakes is *exactly* (I know, I spec'd it) the same one used in the old DPCI-Ring product. That means it's the same board as used in the DN4XXX-series, but with the Aegis boot PROM removed and a node ID inserted in the socket that was always there (way back in the REAL old days, you couldn't even boot an Apollo node without a network card in it because then it wouldn't have a node ID to generate UIDs from, but somewhere along the line we got smart and started putting them on the system board, but that's another story...).

As to IP encapsulation on ATR, Pete is right, the entire basic DDS header, all *70* bytes of it, is there. It has to be or I'd have broken real Domain nodes. Right after the DDS header is a little 12 byte header called the DR header that Domain TCP uses for its own purposes. After that comes a conventional IP packet.

I *didn't* port DDS to HP-UX in order to get ATR support into it. That would have been an extremely time-consuming effort with very little payoff. What I did do is put enough support in the driver to be able to answer lcnode (ask_who, ask_who_notopo, and ask_rem_who) requests, as well as ask_time, ask_bldt, ask_diskless, and ask_node_root. lcnode I *had* to support. If I didn't, I'd again break the existing rings these nodes were destined to go in to. The rest I put in because of the following scenario, which in my opinion is very common:

• lcnode

  long list returned including some uncataloged nodes

• bdlt -n NNNNN

  where NNNNN is some uncataloged node's node id in this case, it turns out to be an HP-UX node, so we return the same string which would be returned by a 'uname -a' command

• ctnode foobar NNNNN -root

  this puts the node into the Domain NS Helper database the next time it is queried with an lcnode

I attempted to violate the "Principle of Least Astonishment" as little as possible, but as Pete put it, we are "a little bit pregnant." There are places where this scheme breaks down, such as the 'lcnode -from' command when run from the other side of a Domain router or when the Domain Automount Daemon (damd) tries to make an NFS mount point in the network root for a node that's already been cataloged this way, but I figure it's still better than a poke in the eye with a sharp stick. ATR on HP-UX is only intended to help customers transition from Domain on ATR to HP-UX on a better network, either FDDI or Ethernet (let's please not have a religious argument about how Ethernet isn't a better network than ATR; the market has already decided that one...), not to be used as the core network of new installations.

Subject: Apollo Domain 19 inch B&W monitor horizontal drift and frequency vistability.

Problem Component: Capacitor C207, a frequency determining element in the horizontal oscillator circuit IC202. This circuit uses a NE555 I.C. in an astable multivibrator configuration. The original component was a polystrene type capacitor which demonstrated a pronounced negative temperature coeficient.

Fix: Replace C207 with either a mylar film or a dipped mica 1000pF capacitor. The oscillator circuit has a fairly narrow range of adjustment such that selection or trimming of value may be necessary. The total value of the replacement capacitor in this case was 1195 pF (1140pF in another).

Procedure: Set the horizontal frequency control to mid range. Connect a frequency counter to pin 3 of IC202 and select or trim the value of C207 until the oscillator hasa free running frequency of 68.219KHz. Free running operation occurs with the 9 pin computer connect cable is disconnected. After obtaining the desired frequency, reconnect the computer cable. The horizontal oscillator should lock immediately. Adjust the horizontal frequency control through its entire range. The oscillator should stay locked throughout most if not all the potentiometer range of adjustment. If drift in horizontal position occurs, it may be due to the polystyrene capacitor C202 used with IC201 the horizontal positioning one shot multivibrator. Its value is also 1000pF and should be replaced with a mylar or dipped mica type capacitor.

Russell Ayling (rayling@rta.nsw.gov.au) has assembled a file of information from an HP source plus bits and pieces picked up here and there. The file is rather long so it's available from:

Carlton B. Hommel <notelrac@world.std.com> has written the file "mac2apollo," which is available via anonymous ftp from:

Every multisync I've tried, to date, has worked on the Apollo's. Even if the monitor does not have RGB BNC connectors, as long as it will support sync on green, there is no real problem. I've been cutting up the Apollo cables and wiring them up to both the 9 pin and 15 pin video connectors. Just solder the red coax to the 'red drive' and the ground to 'red ground' and so on. So far, everything has been working out real nice. If you've got a multisync with the BNC connectors, there is usually an option or switch to allow 'sync on green' and you'll be able to use the Apollo cable.

Another good plug and play monitor that can be used on the color Apollo's is the HP 98751. This is a 19" Sony monitor that is vastly superior to the old Panasonic that Apollo sold. These monitors are going for about $500 on the used market. This monitor has BNC connectors, so it is possible to use the old Apollo cable, makes it 'plug and play'.

From "Operating the Domain Series 3000/Series 4000", pages 2-10 and 2-11:

LEDs During Normal Operation

LED Error Codes

   LED      Power   Hex    Failing Part
   Display  LED     Code
   A B C D  PWR

   o o o o   *      00     CPU
   o o o *   *      01     Memory Module 1
   o o * o   *      02     Display System
   o o * *   *      03     Keyboard
   o * o o   *      04     Memory Module 2
   o * o *   *      05     Memory Module 3
   o * * o   *      06     Memory Module 4
   o * * *   *      07     Disk Drives
   * o o o   *      08     Network Controller-AT
   * o o *   *      09     Cartridge Tape Drive
   * o * o   *      10     EtherController-AT 0
   * o * *   *      11     EtherController-AT 1

   * stands for lit
   o stands for not lit.

From the manual "Operating the Series 10000 Workstation and Server", part number 012880-A00, pages 2-10 and 2-11:

    +----------- Bus indicator:
    |            S = X-bus
    |            U = VMEbus
    |            A = PC/AT bus
    |
    |  +-------- Bus slot number of failing board - X-bus only
    |  |         (ignored on VMEbus and PC/AT bus)
    |  |
    |  |  +----- FRU number of failing board
    |  |  |
    |  |  |  +-- Unit number of FRU - VMEbus only
    |  |  |  |   (ignored on X-bus and PC/AT bus)
    |  |  |  |
   .8..8..8..8.


    S  n  1      X-bus, slot n, X-bus graphics
    S  n  2      X-bus, slot n, X-bus memory board
    S  n  3      X-bus, slot n, CPU
    S  8         X-bus, slot 8, utility board
    U     1  n   VMEbus, winchester controller
    U     2  n   VMEbus, Apollo Token Ring controller
    U     3  n   VMEbus, 802.3 Network controller
    A     1      PC/AT compatible bus, graphics
    A     2      PC/AT compatible bus, floppy/cartridge tape controller
    t            translator board (PC/AT compatible bus)

To test if your Apollo has a working harddrive and an OS installed, put your node in service mode using the little switch on the back of the machine (if it boots up with a > prompt, it's the service mode) and type in:

    > DI W
    > LD

If you have DEX, you can run that to diagnose your machine using EX DEX at the > prompt. For DN10000 there is also SCATMAN which can test your node.

There is a lot of disk information that can be found at:

The simple answer is: sort of. The problem lies with the fact that nearly all the Apollo video cards were developed specifically for the Apollo, not the PC. The Intel platform is byte-backwards relative to the Motorola that the Apollo's have in them; consequentlly, most operations that you perform on the card (put in a char, draw a line, etc) will have to be byteswapped, resulting in extra cycles. Furthermore, the video adapters are entirely bitmapped, meaning they don't understand ASCII characters. Another problem is that the cards live in a large amount of shared memory which makes them unusable as a second display, since they live in the same place where your other display adapters would live. The 8 plane cards can be jumpered to live elsewhere, but unfortunately that is right where the BIOS lives. In addition, the cards wouldn't respond to the BIOS' queries during boot time, so bootup would be done blindly.

It is possible to write a driver to use the video cards, but there are a number of problems. Besides, the SVGA cards on the market are very cheap and would outperform anything you could do with the Apollo cards. Herb Peyerl has done some work in writing a Unix driver for these cards, although he was not very successful. Please contact him for more information.

[ Note: this entry is quite out of date; there have been recent info which tells of using 1280x1024 mono cards in PC's. It is my understanding that the 1280x1024 mono cards can be used under Xfree86 (with Linux or NetBSD) using drivers written by Herb Peyrel and Hamish Coleman. There is some sample code available from the UM Apollo Archive. If you have any information about this, please let me know so that I can include it in the FAQ. ]

The Apollo monitor, though, can be used with PC's provided...

A friend of mine took one of our old Apollo monitors and built a simple sync circuit (consisting of a 74ls02 and a 4066 and a pot. ) for his ATI Ultra card... It works fine in 1024x768 mode which is a bit of a problem if you don't automatically bring up windows on boot or XFree86 or whatever graphics system you're using... I'm in the process of doing a similar thing myself and plan to have two monitors.. One Hercules for regular dos/unix work and then my ATI Wonder/XL with this monitor for Windows/Xfree86...

I've tried the same circuit with the hi-res monitors (1280x1024) and it works even better on those!

This diagram is available via anonymous FTP from:

There is a way to use ESDI drives with an SCSI interface (such as a PC with an SCSI card or a Sun workstation).

It seems that Adaptec makes a translator which allows you to connect ESDI drives to SCSI controllers.

I have an Emulex MD-21 which is the device you want. It is an ESDI to SCSI converter. It controls both 10 and 15 mbit/sec drives and provides a SCSI-1 interface on the other side. The interface will handle two ESDI drives as logical units 0 and 1. (Suns and NeXTs recognize the 2nd logical unit - anyone know if apollos do?) I've had this board connected a wide range of systems (NeXT, Sun, Mac, Apollo) without any problems. This board is a discontinued item, but you can buy them from Sun resellers since they were commonly used in Sun shoeboxes. I paid $40 for mine from such a vendor.

I took a Maxtor 4380E disk drive out of one of our Apollo nodes, and am trying to get it to work on a PC. However, I'm not having much succes.

It's a 386 running DOS 5, and an NCL 5355 disk controller. When I run debug and low level format it, all seems well. It says the proper number of cyl, heads and sectors, but when I run fdisk and format, it thinks its only a 52 MB drive.

I was able to get it to about 150 MB by playing with the CMOS settings, but no higher. Using Norton Utilities, I modified the boot table to a higher number of cylinders, and then fdisk saw 270 MB, but after formatting it, it was unreadable by DOS.

Does anybody out there now how to get one of these disks too work on a PC?

I have used the Maxtor-4380E on several PC's using both Everex and Adaptec ESDI controllers. In both cases, I used debug to low level format the drive (-g=c800:5) using the controller's onboard ROM format utility.

Since DOS has a limit of 1024 cylinders and the drive has 1222 cylinders, when you run fdisk you only see about 270Mb of disk. (I don't know why you are only getting 52Mb).

To use the full 122 cylinders, you need to use the low level format's optional sector translation capability and run 63 sectors per track. Actually, the controller fakes dos into thinking that there are fewer cylinders but more sectors per track.

Using sector translation, my drives after being formatted with dos are coming out to 321Mb. The 52Mb number is strange. Make sure that when you low level format you are using cyl=1222, head=15, spt=36 and then after it formats, do the sector translation to spt=63.

Maybe several of your heads are dead, in which case you should be seeing millions of bad sector entries.......

Hi there. Someone out there must know how to jumper an Apollo disk controller for use in a PC. I've tried several different ones, including the SMS controllers and even a WD7000V-ASE with no luck. The floppy side seems to work just fine... I even think that on one controller I got the IO address space correct, but probably messed up on the DMA channels. I don't know... if anybody out there can help me (Hey old Apollo employees, you listening?) Ideally, of course, I'd like to be able to use the WD7000, but if somebody can help me out using ANY of those controllers I'd really appreciate it.

I've put some time looking into the SMS-OMTI controller. Our determination was that you can't do it for much less than you could buy a new card of equal intelligence. We tracked down SMS somewhere in California, and they faxed us some manual pages on it, so that we could jumper it. The floppy worked fine, but no hard drive. It turns out that there is a jumper to disable the on-card BIOS, which Apollo does. It also turns out that since they disable the BIOS, and they were buying lots of them, they got SMS to remove the BIOS ROM. So now it has absolutely no smarts. If you can find a driver, you may be able to get it to work. Otherwise, SMS charges $40 min plus parts and time to make it back to a real card.

I suspect that you'll need a driver to make the WD7000 work in a PC also - you may be able to buy one from Western Digital.

If you have a WD7000-ASC or WD7000-FASST2 (SCSI only) card pulled from an Apollo, you can use it in a PC to control two floppies and two SCSI HD's without any additional software or drivers if the Boot PROM is still attached to the board. If you are missing the boot PROM or want to use the controller with other SCSI devices, then you will have to get the drivers and possibly a PROM and firmware upgrade from Columbia Data Products. As of 7/26, a firmware upgrade (turns the card into SCSI2) and PROM upgrade (v3.36 is latest) costs $10, and the full drivers and documentation can be purchased for $85. In order to use the WD7000 under Windows 386 Enhanced mode, the PROM revision must be 3.36 (see the README files under Windows 3.1). I have the jumper settings and some helpful files if you want them. I'm still testing this configuration out right now, but once I'm satisfied I will put detailed information in this FAQ.

If you have a WD7000V-ASE, then I am not sure. It is my understanding that the ASE is identical to an ASC, but with additional hardware to support ESDI disks. If this is true, then you should be able to disable the ESDI bus and set the SCSI jumpers properly and use it in a PC, if you have the proper PROMs. If you have any experience with getting the ASE to work in a PC, please let me know, and I'll add the information to the files I have and make it available on this FAQ.

Basically, it is possible and relatively easy to convert an Apollo into an X-terminal by using the standard Domain/OS software. All that is required is to get the machine to boot straight into "Xdomain -query host." The detailed information and procedure to do this is in a file written by Dusan U. Baljevic available from:

If you have an HP9000/400 series running Domain/OS, then you can switch to HP-UX. I believe only up to HP-UX 9.x is officially supported on the Motorola based HP's (9000/3xx, 4xx), but I could be wrong. The following instructions should help you convert from Domain/OS to HPUX.

If you have the original Apollo Domain series workstations, then no. There are no ports of public (or commercial) OS implementations to the Apollo Domain platform. There is some work going on with the NetBSD project team with porting a version of NetBSD to a Motorola based platform (Amiga), but I've been told that this won't be completed any time soon, if at all. BSD4.3 and 4.4 were actually designed on HP 9000/3xx's, which are Motorola based boxes running HP-UX, so there is some groundwork already done there, but unless you have the knowledge, time, effort and the license/access to the source code, porting BSD4.3/4.4 or any other operating system is probably not an obtainable alternative to Domain/OS.

Besides, as every Apollo fanatic would ask, "why would you want to?" Domain/OS already supports BSD4.3 and SV3 programming and user environments in addition to Apollo's Aegis. With a little tweaking and adjusting, you can make your Domain/OS "feel" and "act" like a BSD4.3 system.

Actually, you'll be surprised how well your hardware configuration will run HPUX. We've even converted 400t with 16MB of memory into HPUX boxes and get quite some mileage out of them. Depending on the mix of applications you'll be running, a 425t with 32MB of memory may in some case be as responsive in HP-Vue as a 715 with the same amount of memory, i.e s700 needs lots of memory to perform well.

With all that said, the only reason I'd convert to HPUX is for 3rd-party application support. However, the latest HPUX for s400 (series 400), 9.03, may also be the last release. 3rd-party application support for HPUX on the S400 platform is going down the same road as Domain.

Here're some of my experiences with converting s400 to run HPUX:

1. Keyboard and mouse will need to be replaced (~ $100.00). PC-AT style keyboard is highly recommended.
2. To switch the bootprom from Domain to HPUX mode:
   • At the Mnemonic Debugger prompt, type:

     > CF
     

   • Select option 2 (Boot mode)
   • Select option 2 (HP-UX compatible)
   • Select option to execute and make the selected configuration permanent.
3. Root swap space must be at least the size of physical RAM. Twice the size of RAM is recommended. Further down the road, if some application requires more swap space, use file swap.
4. Depending on the application mix you'll be running, you may have to tune the kernel to increase some system parameters.
5. If you want to use the serial port, you'll have to regenerate a new HPUX kernel with the serial driver (apci) included.
6. If you've more than one system to convert, you can load HPUX and build a source area on the 1st system from physical media, and install the rest of the systems across the network using /etc/update and /etc/netdist.
7. In general, it takes a lot more time to administer a network of HPUX boxes than Domain boxes.

> Has anyone possibly gotten a connector/adaptor to connect an Apollo
> keyboard to a Sun station, or a workaround (do-it-yourself)?

If I remember right, the Apollo's keyboard is connected to an sio serial port (/dev/sio), so it's a bit RS232-like. The connector's pin assignments are:

        CPU end of cable:
              U          1 - +8.5 Vdc (see below)     Red wire
          6o    7o       2 - Data to CPU (TXD)        Yellow wire
                         3 - Logic ground             Green wire
        1o        3o     4 - RESET                    Orange wire
             8o          5 - Data to keyboard (RXD)   Grey wire
          4o    5o       6 - Not used
             2o          7 - Logic ground             Blue wire
                         8 - Not used
                    SHIELD - Chassis ground

        Keyboard end of cable:
            5o  4o  3o  2o  1o
              9o  8o  7o  6o

            2 - +8.5 Vdc (DN3000/3500) or +12 Vdc (DN4000/4500/3550)
            4 - Data to CPU (TXD)
            6 - Logic ground
            3 - RESET
            5 - Data to keyboard (RXD)
            1 - Not used
            7 - Logic ground
            8 - Not used
            9 - Not used
       SHIELD - Chassis ground

The baud rate of Apollo keyboards is 1200 baud. This, as well as some other information on the keyboard's serial interface is reported by /com/tctl -line 0 (SR10.4 doesn't show it, SR9.7 does.)

Additions/deletions to this list and comments about the vendors (good? new stock? still in business?) should be sent to Nickolai Zeldovich <kolya@zepa.net>.

National Peripherals, Inc
1111 Pasquinelli Drive, Suite 400
Westmont, IL 60559
(312) 325-4151

• DNxxxx memory
• 9000/400 series memory?
• Maxtor 8760E (697MB) drives
• SCSI drives for 9000/400's
• Exabyte 8mm tape drives
• Other disk drives, etc.

North Central Peripherals
14041 Burnhaven Drive, Suite 114
Burnsville, MN 55337
(612) 881-2302

• DNxxxx memory
• 9000/400 series memory
• Maxtor 8760E (697MB) disk drives
• Exabyte 8mm tape drives
• Other disk drives, etc.

The ethernet board used in the Otter (DN3000 series) is a 3Com 505. You can buy your own and perhaps save some money. If you buy the board from Apollo, it comes with a special PROM, which you won't have if you buy direct from 3Com. That means you won't be able to boot diskless over the ethernet, or make remote dumps over the ether. But you'll still be able to boot from disk, or over the ring if you have one. And once the node is booted, everything else will work fine.

The 505 is more expensive than some boards, because it has quite a bit of on-board smarts and buffering. No other ethernet board will work in the Otter, unless you want to write your own driver, and even then you will lose the ability to run domain protocols and TCP over the ether, which makes it pretty useless.

Switch settings for the 505 are given in the file ether-switches, available via anonymous FTP from:

I can recommend AMC Computer Services, Inc., 146-B Rangeway Rd., N. Billerica, MA., 01862. Phone: (508)670-9395. They're a group of former Apollo employees who have formed their own depot repair facility for Apollo. They seem to possess considerable expertise and all of our experiences so far have been very positive.

[8.0] MISCELLANY

  DN100/400/420/600        <no name>  (sau1)
  DN300/320/330            Swallow  (sau2)
  DSP80/90                 Sparrow  (sau3)
  DN460/660                Tern  (sau4)
  DN550/560                Stingray  (sau5)
  DN570/580/590-T          Banshee  (sau6)
  DN3500                   Cougar II  (sau7)
  DN4000                   Mink  (sau7)
  DN4500                   Roadrunner  (sau7)
  DN3000                   Otter  (sau8)
  DN2500                   Frodo  (sau9)
  DN10000                  AT  (sau10)
  400s                     Trailways  (030: sau12, 040: sau11)
  400t                     Strider  (030: sau12, 040: sau11)
  400e                     Woody  (sau11)
  DN5500                   Leopard  (sau14)

HP9000/400[ste] boxes did not have 68040. 400's had a 68030 at 50 MHz, 425's had a 68040 at 25 MHz, and 433's had 68040 at 33 MHz. The 400's were sau12, while 425s and 433s were sau11.

Also, DSP160 is sau4, and probably Tern too.

% stcode 1D01001E
Vendor "Apollo" can not be deleted (network license server/server)

How about 13010008: trait not supported for wicked far-away objects (object based systems/trait manager)

My favorite is still 220009: unit will not fit thru 25" hatch (OS/magtape manager)

This refers to a large computer manufacturer (former employer of some of the Apollo OS folks) that once bid on a government contract to supply computing equipment for use on board submarines. They lost the contract when the government discovered that the tape drive would not fit through the 25 inch hatch used to load equipment onto a submarine. Anything that won't fit through the hatch has to be loaded by cutting a hole in the hull.

Contributors

• David K. Ahn of Wake Forest University was the maintainer of this FAQ from February 7, 1994 to November 20, 1996.
• Morgan Ryan of Neil Paterson Publishers was co-maintainer of this FAQ from February 7, 1994 to July 28, 1994. Many thanks to him for his time and effort, particularly in reformatting this FAQ.
• Willem Jan Withagen of Eindhoven University of Techonology, The Netherlands, was the maintainer of this FAQ from March 25, 1992 to February 7, 1994. The effort Willem put forth to provide this service to Apollo users has been invaluable and is greatly appreciated!
• Jim Rees <Jim.Rees@umich.edu> of University of Michigan was the maintainer of this FAQ before Willem Jan Withagen, and he continues to make significant contributions with his help and knowledge.