Apollo Frequently Asked Questions


Last Updated: Mar 29, 2012
Previous Update: Dec 28, 2001
Revision: 5
This is the Apollo Frequently Asked Questions file. It has been compiled from many sources. Many thanks to all contributors.

The FAQ is available from http://web.mit.edu/kolya/www/csa-faq.html.

All comments about this FAQ and suggestions for additions or deletions should be sent to the current maintainer, Nickolai Zeldovich.


Disclaimer

This FAQ (and the mentioned files) is presented with no warranties or guarantees of ANY KIND including correctness or fitness for any particular purpose. The author(s) of this document have attempted to verify correctness of the data contained herein; however, slip-ups can and do happen. If you use this data, you do so at your own risk.

Table of Contents

[ + means updated or new since last revision of FAQ ]

[1.0] GENERAL QUESTIONS

[2.0] USER AND ENVIRONMENT

[3.0] X-WINDOWS AND DISPLAY MANAGER

[4.0] SYSTEM RELATED SOFTWARE

[5.0] SYSTEM RELATED HARDWARE

[6.0] SALVAGING OLD APOLLOS

[7.0] THIRD-PARTY VENDORS

[8.0] MISCELLANY


[1.0] GENERAL QUESTIONS

[1.1] Where can I get online information about my Apollo?

An archive of the comp.sys.apollo newsgroup was started in November 1989 by Willem Jan Withagen (wjw@ebh.eb.ele.tue.nl), and is now maintained by Jim Richardson (jimr@maths.usyd.edu.au). Search these indexes for a wealth of information about topics discussed in the newsgroup in the past. The comp.sys.apollo archive is reachable via a keyword search interface at: http://www.maths.usyd.edu.au:8000/csa.html.

( 8/12/96, Paul Szabo <psz@maths.usyd.edu.au> )

Some information on Apollo machines can be found at http://www.zepa.net/apollo including some data on Apollo's CPUs and node types.

(20/14/96, Nickolai Zeldovich <kolya@zepa.net> )

Also try the following:

(26/03/98, Paul Szabo <psz@maths.usyd.edu.au> )

[1.2] How do I keep up with patches and software changes?

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:

To get more information about HPSL, send a message to support@support.mayfield.hp.com (no Subject required) with the body of:

send guide

The guide is formatted using nroff. To get an ASCII version of the guide, replace the "send guide" with "send guide.txt".

When you get an official patch, it includes something like patch_{m68,a88}k_yymm_notes, which are descriptions of the patches up to the month mm in year yy.

You'll read something like this:

"These notes describe the software patches for m68k Domain Systems. This patch kit includes patches released since July, 1992 for SR10.x versions of the Domain/OS operating system and for SR10-based optional products. When one of these patches requires installation of another patch released prior to July, 1992, we also include and document that patch." (from NOTES)

Be careful to note which patches supercede another.

The SSB is the Domain/OS Software Status Bulletin. According to the SSB:

"This Software Status Bulletin (SSB) documents known problems in the DOMAIN/OS software product line. The SSB is derived from Known Problem Reports which results from Service Requests (SR) submitted by users of these products. The SSB is provided as a benefit of Hewlette- Packard's Account Management Support, Response Center Support, Software Materials Subscription, and Software Notification Service.

"Not all SRs submitted to HP are listed in the SSB. Ones which involve problems which cannot be duplicated, requests for enhancements and misunderstandings about an application or a feature are not listed in the SSB. When a new software release is made for the product line, all problems that were corrected in that release are removed from the SSB.

"Please note that all defects fixed in SR10.4 and related releases have been removed from the SSB and published in the Domain OS Software Release Bulletin (SRB) available on the SR10.4 media as /install/doc/apollo/os.v.10.4__release_notes_bulletin

( 2/24/94, Willem Jan Withagen <wjw@eb.ele.tue.nl>, Dave Ahn <ahn@hbar.phy.wfu.edu> )

Now HP offers access to their patches at http://us.external.hp.com/ where you can browse and/or download their patches. The instructions for getting the patches are a bit wrong. While they say they will send you a wbak image of the file you will need to rbak, they actually send you a shell script which you need to run in order for it to uncompress itself.

(20/14/96, Nickolai Zeldovich <kolya@zepa.net> )

[1.3] What is ADUS? And Interworks?

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:

Carol Relph
Workstation Business Unit, HP
300 Apollo Drive, IWORKS
Chelmsford, MA 01824
Phone: 508-436-5046
Fax: 508-256-7169
Email:
relph_c@apollo.hp.com

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[1.4] Where can I get "foo" for my Apollo (for all values of "foo" where "foo" is some freely available software package)?

Good places to find Apollo-specific code are:

Also try the following:

There are some Apollo related documents and a limited collection of patches and source code available from:

( 7/26/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )


[2.0] USER AND ENVIRONMENT

[2.1] Is there a termcap entry that will work correctly with the vi editor?

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.

Pads are not terminals.
Workstations were supposed to obsolete terminals.
But they didn't.
But pads still aren't terminals.

( 2/15/94, Kee Hinckley <nazgul@alphalpha.com> )

[2.2] Which Emacs do I want?

Short answer: If you mostly use the DM, get Leonard N. Zubkoff's modified gnu emacs 18.59 from lucid.com. If you mostly use X, get gnu emacs version 19 and a patch file from archive.umich.edu, get it to run, and send me any changes required.

For the latest list of emacs implementation, see the file ftp://mail.unet.umn.edu/import/fin/emacs

Some terminology: A "screen" is like an X window or a DM pad. It's a view into one or more files that's individually resizable and movable around your display. On a dumb vt100 you can only have one screen, although you might have multiple emacs windows. With the DM or X you can have multiple screens, each with (possibly) multiple windows.

Here are the choices for emacs on Domain/OS, as I see it.

First, if you just want to make the DM look a bit like emacs, there are keydefs somewhere to do that. I'm not sure where. There is also an elisp package called x-apollo.el that makes your emacs look more like the DM.

If you want an emacs lookalike that's easier to build and lighter weight than the real thing, but isn't extensible (doesn't have elisp), look at jove. It only runs on vt100-like devices, so is single-screen. There is a version for Domain/OS on archive.umich.edu.

If you want the real thing, you really need gnu emacs or one of its descendants. The grandfather of these is probably gnu emacs 18. It's been around a long time and is stable, and will run in a DM pad using gpr, on a vt100 connected via tty or pty, or in an X window. It is single-screen only. It is available from the usual gnu ftp sites, but as distributed by gnu it's configured for sr9.7 and won't dump. If you want to run emacs 18 you should look at the special Apollo version put together by Leonard N. Zubkoff, available for ftp from lucid.com.

Source patches to build this version (but not executables) are available from archive.umich.edu.

Gnu emacs 19 runs in multiple X screens (gnu emacs calls them "frames") or on a tty. I don't think it will run in a DM pad, but I could be wrong; I think the code is still there to do this. It requires patches to run on Domain/OS. Some patches are available from archive.umich.edu, but gnu emacs 19 is a moving target, so check on comp.sys.apollo before trying to build, and please share your experiences with us. It is available from the usual gnu ftp sites.

Epoch runs in multiple X screens, and can have a single shared minibuffer or separate minibuffers attached to each screen. It won't run in a DM pad or on a tty. It is currently being merged into lemacs (see below) and is no longer maintained. The last version is 4.2. It requires no patches to run on Domain/OS and is available by ftp from cs.uiuc.edu.

Lucid emacs (lemacs) runs in multiple X screens. For a description, see the file ftp://lucid.com/pub/lemacs/README. Lemacs will not run on a tty. It requires an ANSI C compiler to build and will not run unmodified on Domain/OS. It may be possible to apply part or all of the epoch or emacs 19 patches (available from archive.umich.edu) to get it to work. If you do this, please let me know. Lemacs is available by ftp from lucid.com, cs.uiuc.edu, and liasun3.epfl.ch.

( 3/3/94, Jim Rees <Jim.Rees@umich.edu> )

[2.3] How do I get my Emacs key definitions back when running under X?

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:

(load "x-apollo-keys" nil t)

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

[Maintainers note: The file "x-apollo-keys.el" is ~350 lines, and is stored at ftp://ftp.eb.ele.tue.nl/pub/apollo/pd-progs/x-apollo-keys.emacs]

( 2/15/94, Kevin Gallagher <kgallagh@digi.lonestar.org> OR <!uunet!digi!kgallagh> )

[2.4] Do you have a problem with GNU Emacs' C-x` command?

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!

( 2/15/94, Michael K. Gschwind <mike@vlsivie.tuwien.ac.at> )

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):

        0 4 * * 7 root /usr/local/lib/fix_ptys

and here is /usr/local/lib/fix_ptys:

        #!/bin/csh -f
        /bin/rm -f /dev/[pt]ty[pq][0-9a-f]
        /etc/crpty 32

( 2/15/94, Jinfu Chen <chen@digital.sps.mot.com> )

[2.5] Why can't I login as root anywhere except a DM pad?

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

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[2.6] How can I determine the load average without /dev/kmem?

  getla()
  {
      long avenrun[3];
      proc1_$get_loadav(avenrun);
  }
( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

[2.7] Where can I get the latest versions of GCC, G++ and GDB for my Apollo?

GCC 1.37.1, G++ 1.37.1 and LIBG++ 1.37.0 for Apollo 68k platforms are available via anonymous FTP from ftp://labrea.stanford.edu/pub/gnu as APOLLO* and apollo* files.

GDB 4.12 will work on Apollo's with a small patch. This version of GDB reads Apollo native debugging information, so you do not need to compile our programs with GCC and GAS to use GDB. GDB is massively faster in all respects than the Apollo debuggers DDE and DBX. GDB 4.12 has been tested on SR10.4 under BSD4.3. The patch and instructions on compiling are available via anonymous FTP from ftp://ftp.wfu.edu/usenet/apollo/src/gdb4.12-apollo.gz

Recent versions of GCC and G++ have been ported to the Apollo platform (2.5.x). The patches and compilation information are available from ftp://ftp.eb.ele.tue.nl/pub/apollo/gcc

( 3/18/94, Troy Rollo <troy@cbme.unsw.EDU.AU>, Dave Ahn <ahn@hbar.phy.wfu.edu> )

Versions of GCC, GAS and GDB for Apollo are now available from ftp://archive.umich.edu, http://pisa.citi.umich.edu, and gopher://gopher.archive.merit.net:7055/11/apollo in the files gdb+gas.tar.gz and gcc-2.4.5.tar.gz. These versions support Apollo's native DST information. GDB is version 4.12 and GAS is version 2.2. gdb+gas will need to be compiled with a previous version of GCC. You should compile (and install) gdb+gas before compiling gcc, otherwise gcc will fail in stage 2. The steps to get going are (roughly):

  1. Unpack the tar.gz files
  2. cd gdb+gas
  3. ./configure
  4. make
  5. cp gdb/gdb /usr/local/bin/gdb
  6. cp gas/as.new /usr/local/bin/as
  7. cd ../gcc-2.4.5
  8. ./configure m68k-apollo-bsd
  9. run the patch-apollo-includes script (from README.apollo)
  10. make "LANGUAGES = c"
  11. make stage1
  12. make "CC=stage1/xgcc -Bstage1/" "CFLAGS=-g -O"
  13. make stage2
  14. make "CC=stage2/xgcc -Bstage2/" "CFLAGS=-g -O"
  15. make compare (to verify it all went OK)
  16. make install

Note that these versions are not compatible with Chak Kolli's stabs in COFF patches.

( 7/28/94, Troy Rollo <troy@cbme.unsw.EDU.AU> )

A set of patches for the GNU assembler, C compiler, and debugger are available by FTP from hoffman.rstnu.bcm.tmc.edu (128.249.31.10) in /pub/gnu. It is also reachable by WWW at http://hoffman.rstnu.bcm.tmc.edu/ These add some Apollo language extensions to GCC. They have been tested on a DN4500 running SR10.3.5 using the BSD environment. They use the GNU "stabs" format debugging records rather than the Apollo format.

Files:

    README                brief description of files, installation
    apolgas-2.3.tar.Z     patch kit for gas-2.3,    the GNU assembler
    apolgcc-2.6.0.tar.Z   patch kit for gcc-2.6.0,  the GNU C compiler
    apolgdb-4.13.tar.Z    patch kit for gdb-4.13,   the GNU debugger
    apollibg++-2.6.tar.Z  patch kit for libg++-2.6, the GNU C++ library

( 9/22/94, William J. Eaton <wje@hoffman.rstnu.bcm.tmc.edu> )

[ Jim Rees has voiced concerns that this distribution format might violate the GNU public license. If you have updated information on GCC/GDB/GAS for the Apollo, please contact me. I'm particularly interested in the latest versions supported for the Apollo as well as its stability/compatibility/etc. -- David K. Ahn ]

[2.8] Where can I get an assembler?

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.]

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[2.9] Why doesn't "vi" and/or "vt100" work anymore? Why does telnetd/rlogind tell me "out of ptys" when I connect to my Apollo?

>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?

( 3/17/94, Jk <jk@cse.iitb.ernet.in> )

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

/etc/mkdev /dev pty

( 3/17/94, John Thompson <thompson@space.honeywell.com> )

[2.10] Can I get Emacs to parse the Apollo C compiler error output?

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

( 2/15/94, Anthony Bowles <anthonyb@comm.mot.com> )

[2.11] How can I compile httpd on my Apollo?

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

( 7/13/94, Vince Skahan <vds7789@aw101.iasl.ca.boeing.com> )

[2.12] Where can I get Internet browsing tools (Mosaic, etc) for the Apollo?

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.

( 9/21/94, Jim Rees <Jim.Rees@umich.edu> )


[3.0] X-WINDOWS AND DISPLAY MANAGER

[3.1] Where can I get X11R4? X11R5? X11R6?

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:

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:

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

( 3/3/94, Jim Rees <Jim.Rees@umich.edu>, Donie Collins <collins@prl.philips.nl>, Ken Steege <kens@hpcvusc.cv.hp.com> )

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.

(20/11/96, Nickolai Zeldovich <kolya@zepa.net> )

[3.2] Why is X so slow at SR10.2?

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

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[3.3] I only have X11R3...can I still run R4/R5 clients?

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.

( 3/3/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[3.4] When I try to compile an X Application, I get errors. Why?

        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...

( 3/3/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[3.5] Are the VT100 PF1-PF4 keys defined in the Apollo version of XTerm?

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."

( 2/15/94, Walt Weber <weber_w@apollo.hp.com> )

[3.6] What else should I know about X keysyms?

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

( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

[3.7] How can I use a DM font under X?

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?

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[3.8] Can I convert my Apollo into an X-terminal?

(see section on SALVAGING OLD APOLLOS)

[3.9] What (display) MGRS are needed for what type of system?

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.

( 2/15/94, John Thompson <thompson@pan.ssec.honeywell.com> )

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. ]

( 2/ 3/94, Rob Raymond <rlr@hpfela.fc.hp.com>, Russell Ayling <rayling@rta.nsw.gov.au> )

[3.10] How can I get auto word-wrapping in the DM editor?

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

( 2/15/94, Fred Stluka <stluka@software.org> )

[3.11] I want to use my Apollo to program some graphics. What do I need to know?

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:

So I would recommend GPR. Look in /domain_examples to see if there are any GPR examples. GPR is quite hard work, but if you put in some effort, you can get some very good results.

( 7/25/94, Dan Bennet <dan@hpwina39.uksr.hp.com> )

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.

( 8/5/94, Russell Ayling <rayling@rta.nsw.gov.au> )

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.

( 1/22/97, Nickolai Zeldovich <kolya@zepa.net> )


[4.0] SYSTEM RELATED SOFTWARE

[4.1] Where can I get a version of sendmail that supports MX records? Does this or that version of sendmail work on Apollos?

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 ftp.maths.usyd.edu.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:

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

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.

( 2/15/94, Paul Killey <paul@CAEN.ENGIN.UMICH.EDU> )

[4.2] What is "Unknown mailer error 1?"

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.

( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

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.

( 2/15/94, Bruce Orchard <orchard@eceserv0.ece.wisc.edu> )

[4.3] How can I use the DM editor for mail or while su'ed?

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 ftp.maths.usyd.edu.au or ftp.eb.ele.tue.nl.

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[4.4] What do I need to run the Post-Office daemon (POP-daemon)?

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: ftp://ftp.eb.ele.tue.nl/pub/apollo/local/etc/popd

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

I think that's version 2 of the protocol. You might want to try version 3: ftp://ee.utah.edu/pop3/popper-1.831beta.tar.Z

It installed without any problems on a DN3500/OS10.3 and seems to be working well with WinQVT/net running on a PC...

( 2/15/94, Bill Neisius <bill@solaria.hac.com> )

[4.5] What should I know about Apollo/NFS?

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.

( 8/5/94, Russell Ayling <rayling@rta.nsw.gov.au>, Eric Bratton <ericb@caen.engin.umich.edu> )

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.

( 3/3/94, Chuck Tomasi <chuck@edsi.plexus.com>, Scott Cokely <cokely@nb.rockwell.com> )

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.

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.

( 2/15/94, John Thompson <thompson@pan.ssec.honeywell.com> )

[4.6] When I try to use NFS on my IBM PC to access files on my Apollo, it complains about not finding an "Authentication Server." What gives? Where is PCNFSD for Apollo's? How do I compile PCNFSD?

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:

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:

(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 )

( 2/15/94, Willem Jan Withagen <wjw@eb.ele.tue.nl> )

[4.7] Why doesn't Apollo FTPD support anonymous FTP?

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.

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[4.8] Where can I get proxy ARP?

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

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[4.9] How do I enable IP name service?

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

( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

[4.10] Why does routed not work for long periods of time under SR10.2? Are there any known TCP/IP problems with routing?

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.

( 2/15/94, Eric Bratton <ericb@caen.engin.umich.edu> )

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

/etc/tcpd

to

/etc/tcpd -b -p0

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).

( 2/15/94, Keith Marlow <marlow@sys.uea.ac.uk> )

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.

( 7/15/94, Jim Rees <Jim.Rees@umich.edu> )

[4.11] How well does SLIP work? How about PPP?

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 <my ip address> <ip address of terminal server>
    /etc/route add default <ip address of terminal server> 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).

( 2/15/94, Nat Mishkin <mishkin@apollo.hp.com>, Jim Rees <Jim.Rees@umich.edu> )

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

[4.12] Can I use TERM instead of SLIP?

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.

( 3/3/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[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 ]

( 2/15/94, Mike Peterson <system@alchemy.chem.utoronto.ca> )

[4.14] How can I get my printer to work?

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

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:

( 2/15/94, Paul Szabo <szabo_p@maths.usyd.edu.au> )

[4.15] Why do I get "cannot start daemon" when I try to use lpr? How do I get BSD style lpr/lpd to work?

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 #>

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!).

( 2/15/94, David Todd <hdtodd@eagle.wesleyan.edu> )

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.usyd.edu.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.usyd.edu.au}"  /bin/rm -f /tmp/print.u

Hope this will help someone.

( 3/17/94, Paul Szabo <szabo_p@maths.usyd.edu.au> )

[4.16] Why do I get: Unable to go into maintenance state. User not authorized to perform operation (network computing system/Registry Server)? How can I back up the registry?

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?

( 2/15/94, Robin Brown <robinb@resmel.bhp.com.au> )

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).

( 2/15/94, Joe Pato <pato@apollo.hp.com> )

[4.17] How do I find out about and fix bad spots on my disk?

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:

( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

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.

( 2/15/94, Paul Szabo <szabo_p@maths.usyd.edu.au> )

[4.18] What do I need to emulate a PC on my Apollo? What is DPCC, DPCE and DPCI?

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

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[4.19] How do I prevent a system hang when booting while preserving editor files?

>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.

( 2/15/94, Kenneth Lee Atchinson <edsverk@ed4000-2.lerc.nasa.gov> )

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.

( 2/15/94, Mike Peterson <system@alchemy.chem.utoronto.ca> )

[4.20] How can I do postscript accounting?

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://ftp.maths.usyd.edu.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.)

( 2/15/94, Paul Szabo <szabo_p@maths.usyd.edu.au> )

[4.21] How can I keep my node clocks synchronized?

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 ]

( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

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

We start it from rc.local as follows:

/etc/timed -M -n <name of the local network>

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:

/etc/timed -M

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

/etc/timed -n <name of the local network>

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:

>EX CALENDAR

to set date and time, and wait for the amount of time that you had set the clocks backwards before rebooting. This avoids duplicate time stamps. For all this to work correcty, TCP/IP has to be installed properly.

( 2/15/94, Annegret Liebers <annegret@combi.math.tu-berlin.de> )

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.

( 2/15/94, Robert Stanzel <rps@apollo.hp.com> )

[4.22] I can't get my rgyd or registry database to work. What can I do?

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.**

( 7/28/94, John Stephens <stephens@lobby.ti.com> )

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.

( 7/28/94, Carl H. Heidrich <chh@chh.ikp.uni-bonn.de> )

[4.23] What does "Returned status (from pm_$init): XXXX" mean?

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.

( 7/28/94, Jon Granrose <granrose@scz.ssi1.com> )

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.

( 7/28/94, Simon Favre <simon@lsil.com> )

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.

( 7/28/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

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.

( 8/5/94, Russell Ayling <rayling@rta.nsw.gov.au> )

[4.24] How do I break into an Apollo running Domain/OS? How about Aegis or Domain/IX?

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

( 8/30/94, Paul Szabo <psz@maths.usyd.edu.au>, 1/12/98, Nickolai Zeldovich <kolya@zepa.net> )

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

If this command fails with "not enough rights" or a similar message, your system has likely been secured more than the default installation, and you will need to break in by using another Apollo node on a network, or reinstalling it.

However, if the command works, you should now have an empty regisry. To initialize a registry, follow these procedures (from "Administering Your Domain System", SR9 style):

If you are running Domain/IX, you need to do the same thing, except after doing it, read /install/inst_registry_both to setup the registries with root and such BSD/SysV accounts.

(20/11/96, Nickolai Zeldovich <kolya@zepa.net> )

[4.25] What is the date bug in Domain/OS and Aegis?

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:

rbak -l -all -ms -pdt -from PD9X_XXXXX -as //aa_node/install

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.

( 5/12/96, Jim Rees <rees@umich.edu> )

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...

( 5/12/96, Paul Szabo <psz@maths.usyd.edu.au> )

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/12/96, <lbayuk@delphi.com> )

HP has released a new patch and withdrawn the broken one. The new patch from HP is PD96_M0748. It contains the same /lib/kslib that HP offices were giving out to selected customers who begged for it before the patch came out. Patch PD96_M0739 is superseded and withdrawn. There is a letter from HP explaining the Nov 2, 1997 problem which found its way to http://www.InterWorks.org/Tech/apollonov2/ I've had people tell me they set clocks forward past Nov 2, 1997 and ran without problems, but this letter from HP explains that empirical testing is not sufficient.

( 7/ 6/97, <lbayuk@delphi.com> )


[5.0] SYSTEM RELATED HARDWARE

[5.1] What is the story on adding more disks to my node?

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).

[ Note: The restriction on having only one of {tape, floppy} may or may not be true; 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:

[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.

For info on turning an ESDI disk into an SCSI disk, see the section on SALVAGING OLD APOLLOS.

For more information, consult the "disk-info" file available from ftp://ftp.wfu.edu/usenet/apollo/doc/disk-info.

( 8/30/94, John Thompson <thompson@pan.ssec.honeywell.com>, Dave Ahn <ahn@hbar.phy.wfu.edu>, Russell Ayling <rayling@rta.nsw.gov.au> )

I believe large drives are supported from SR10.4.1 only. I do not think you can get older INVOLs to talk to the drive. Even at SR10.4.1 you may need a 425t, instead of the DN2500, to be able to use them.

My own story: I had a Quantum PD425iS (420MB) in a 425t running 10.4 (and earlier probably 10.2). I wanted to replace this by a Quantum 2100S (2100MB), but failed with the same type of error you got until I installed SR10.4.1. Curiously, /systest/ssr_util/scsi_info reported both disks to be SCSI-2. Around the same time I also wanted to install a Seagate ST5660N (540MB, also SCSI-2) into another, previously diskless, 425t, and only succeeded at SR10.4.1.

Note that between SR10.4 and SR10.4.1, only the sau11 and sau12 versions of 'EX INVOL' (/sau*/invol) have changed; the online version /etc/invol did not change between SR10.4 and SR10.4.1. I cannot readily check older INVOLs. At SR10.4.1:

  # /bsd4.3/bin/ls -l /*/invol
  lrwxrwxrwx   1 root           12 Mar 14 11:59 /com/invol -> ../etc/invol
  -rwx------   3 root        88053 Dec 31  1991 /etc/invol
  -rwxr-xr-x   1 root       614283 Nov 21  1993 /sau11/invol
  -rwxr-xr-x   2 root       606091 Nov 21  1993 /sau12/invol
  -rwxr-xr-x   3 root       514714 Dec  4  1991 /sau14/invol
  -rwxr-xr-x   3 root       308890 Dec  4  1991 /sau7/invol
  -rwxr-xr-x   3 root       268954 Dec  4  1991 /sau8/invol
  -rwxr-xr-x   3 root       296313 Jan  1  1992 /sau9/invol

(25/11/96, Paul Szabo <szabo_p@maths.usyd.edu.au> )

>>>> Anyone have any experience using a Seagate 31200N SCSI drive on an
>>>> Apollo DN2500?
>>> What version of the OS are you running?
>> No, the DN2500 was/is a SCSI based machine. It does not use ESDI drives 
>> like the DN{345}xxx series machines. The OS rev is irrelevant (as
>> long as it supports sau9).
> I know the 2500 is SCSI basedd, but that doesn't explain the problme. 
> Perhaps the change mode call relies on some support not present in
> earlier release of the OS, perhaps not.

I am sure the OS version is relevant here. I had two disks, a Quantum 2100S (2GB) and a Seagate ST5660N (540MB), which I had to install into 425t's. I did not seem to have much luck with them, with almost exactly the symptoms the original poster described. I also tried to change the disks to SCSI-1 with mts, without luck; anyway, one of the target machines already had a disk, which /systest/ssr_util/scsi_info claimed to be SCSI-2 (Quantum PD425iS 420MB, to be replaced by the 2GB disk), so this could not have been the problem. Another Apollo user said I might need to get upgraded boot PROMs to support larger disks. But then, I upgraded to SR10.4.1 (from SR10.4), and everything worked like a charm! (My memory is somewhat vague, I am not sure if someone suggested to upgrade, or if it was just a temporal coincidence.)

In summary, it seems to me that large SCSI disk are (better? only?) supported since SR10.4.1. I would suggest to upgrade to SR10.4.1 and then try again.

(25/11/96, Paul Szabo <szabo_p@maths.usyd.edu.au> )

I read in the FAQ that you couldn't have both the FLOPPY and the SCSI Cartridge drive active on the WD7000 controller. This is demonstrably false for my 3500 which is runing Domain/OS 10.3.5.15, but it also works in DEX.

... I currently have the 3500 with the WD7000 installed and jumpered according to the "jumper" program and it reads and writes to the non-scsi floppy and the SCSI cartridge drive just fine. (I haven't tried both at the same time, but I don't see why this wouldn't work.)

(28/08/99, Philip Pokorny <ppokorny@mindspring.com> )

[5.2] I'm trying to get an SCSI-2 type disk to work with my Apollo, but it doesn't seem to work. What did I do wrong?

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.

( 2/15/94, Michael Lampi <lampi@mdlcorp.com> )

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?

( 2/15/94, Willem Jan Withagen <wjw@eb.ele.tue.nl> )

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.

( 2/15/94, Dave Krowitz )

On SR10.3.5.15 fully patched with patch kit PD97_MPB09 I was able to format a 4.3Gig drive on my 433t. This drive was a Seagate ST15150N. The format was done with online invol and I had to make no special changes to the drive firmware whatsoever. It worked right out of the box (except for setting the SCSI id). Here is the drive description as reported by scsi_info:

Target 5:
Device Type: Disk
Vendor: SEAGATE
Product: ST15150N
Rev Level: 0023
ANSI version compliance: SCSI-2
Features supported: Synchronous Data Xfer; Linked Commands; Cacheing;
Command Queueing;
0 bytes of vendor unique data

After running option 7 of invol (initialize bad spot list) and formatting the drive, I initialized the virgin physical volume with the '-f' option and it reported 4166892 kbytes free. After the logical volume was created (1 full partition of 4Gig), I was able to mount the drive and begin using it with no problems. I have yet to run into any as well. The entire process from install to mount took 4 hours.

( 8/9/98, Joe Avila <joe@avilate.com> )

[5.3] Can I use Exabyte tape units on my Apollo? Do I need to buy Omniback to use my Exabyte 8mm tape drive?

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:

mt /dev/rmts9 -scsi rewind

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.

( 3/28/93, Chris Folland, Jim Waldram <waldram@grizzly.uwyo.edu> )

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.

( 2/15/94, David Krowitz <krowitz@richter.mit.edu> )

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).

( 2/9/93, Michael Lampi <lampi@mdlcorp.com> )

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.

( 2/15/94, Frank Teusink <frankt@cwi.nl> )

[5.4] How can I read cartridges written on Sun systems?

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.

( 2/15/94, Harald Hanche-Olsen <hanche@imf.unit.no> )

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.

( 2/15/94, David Krowitz <krowitz@quake.mit.edu> )

[5.5] How can I use wbak to write stdout to a Sun workstation's tape?

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.

( 2/15/94, <rmallett@ccs.carleton.ca> )

[5.6] Can I use DAT drives to back up Apollos?

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.

( 2/15/94, Paul Szabo <szabo_p@maths.usyd.edu.au> )

[5.7] How do I install an ethernet card in my Apollo DN[345]x00?

This information is available by anonymous FTP at: ftp.wfu.edu:/usenet/apollo/doc/ethernet.info

( 3/4/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[5.8] Why does my DN10000 ethernet interface stop working?

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).

( 2/15/94, Mike Peterson <system@alchemy.chem.utoronto.ca> )

[5.9] Has anyone else experienced power-supply problems with their Apollo DN10000?

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).

( 2/15/94, JJW <waldram@grizzly.uwyo.edu> )

[5.10] Why does my 8MB memory card work on a DN3500 but not in a DN4500?

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.

( 3/4/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[5.11] What are the conections in a 3-way serial port splitter?

  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.

( 2/15/94, Willem Jan Withagen <wjw@ebh.eb.ele.tue.nl> )

[5.12] Can I add serial ports to DN[345]x00 nodes? How about an internal modem? Why does my Apollo look like it has an IBM AT bus? Can I use PC ISA cards in my Apollo?

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! :)

( 3/4/94, Philip D. Pokorny <philip@cel.cummins.com>, Dave Ahn <ahn@hbar.phy.wfu.edu> )

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.

( 7/26/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

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.

( 3/22/94, Frederick Roeber, <roeber@vscrna.cern.ch> )

[5.13] What is the use of an ATR card in an HP9000/7xx?

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:

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.

( 2/15/94, Carl Davidson <ced@apollo.hp.com>, Herb Peyerl <hpeyerl@novatel.cuc.ab.ca>, Peter E. Giza <giza@apollo.hp.com> )

[5.14] My 19" monochrome monitor flickers. What can I do?

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.

( 2/15/94, Ricky Houghton <houghton@iuvax.cs.indiana.edu> )

[5.15] What are the specs of monitors once sold by HP/Apollo?

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: http://www.umich.edu/~archive/apollo/monitor-info

( 3/4/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[5.16] How can I connect my Macs to my Apollo?

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

( 3/4/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[5.17] Can I use a non-Apollo monitor on my Apollo?

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'.

( 9/21/94, Mike Thomas <thomasm@agcs.com> )

[5.18] What are the meanings of the front-panel LEDs on the DN[345]xxx and DN10000? The 400 series machines?

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.

(20/11/96, Nickolai Zeldovich <kolya@zepa.net> )

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)

(20/11/96, Paul Szabo <szabo_p@maths.usyd.edu.au> )

Looking in the manual "HP Apollo 9000 Series 400 Workstation, Domain/OS, Owner's Guide" (Order No. A1630-90005, Part No. A1630-90605), pages 5-10 to 5-14:

LED Error Codes

... There are ten LEDS on the front panel. The green LED is labeled "P" and indicates that the system is powered up. When the Service LED is on, it inidicates that the system is in Service mode. When the Service LED is off, the system is running in Normal mode (normal everyday operation). The amber LEDs labeled "A" through "H" indicate system status.

Table 5-11 shows the codes displayed by the LEDs during normal system operation. Note that the "Network Receive In Progress" and "Network Transmit In Progress" codes can flash so rapidly that they appear as a steady (not flashing) display.

Table 5-11 LED Codes

   LED Display
   (A through D Flashing)   Message

   P A B C D E F G H S
   O - - - O - - - - -      Operating System Running
   O - - O - - - - - -      Disk Access in Progress
   O - O - - - - - - -      Network Receive In Progress
   O O - - - - - - - -      Network Transmit In Progress

   S = Service Mode Indicator
   On = Service Mode
   Off = Normal Mode
   P = Power-on Indicator

Boot PROM Diagnostics LED Error Codes

If an error occurs during the power-up diagnostics tests, the diagnostics use the front panel LEDs to display a code for the failing Field Replaceable Unit (FRU). Note that the power LED is always on when the system is powered on, and that the Service mode LED is on only when the system is in Service mode.

If the system is in Normal mode and an error occurs, you receive a prompt that asks if you wish to continue the tests and try to boot the operating system; the LEDs and the display screen show the failing FRU and system status. If the system is in Service mode and an error occurs, the tests halt, with the LEDs and the display screen showing the failing FRU and system status.

Table 5-12 shows the FRU code display and hexadecimal numbers for the system as they appear on the front panel display. Use these LED codes to determine the failing FRU.

Table 5-12 illustrates the LEDs on the front panel that are used to call out the failing FRU during the CPU/Motherboard/Memory testing. ... Once the CPU/Motherboard/Memory is tested, the diagnostics use the display screen to report the test status. The screen displays any failing FRUs.

Table 5-12 LED Codes for FRUs

   LED Display              Field Replaceable Unit Name         Hex Code

   P A B C D E F G H S
   O - - O O - - - - -      SCSI Device 0                       30
   O - - O O - - - O -      SCSI Device 1                       31
   O - - O O - - O - -      SCSI Device 2                       32
   O - - O O - - O O -      SCSI Device 3                       33
   O - - O O - O - - -      SCSI Device 4                       34
   O - - O O - O - O -      SCSI Device 5                       35
   O - - O O - O O - -      SCSI Device 6                       36
   O - - O O - O O O -      SCSI Device 7                       37
   O - - O O O - - - -      Network Interface Board             38
   O - - O O O - - O -      Graphics Interface Board            39
   O - - O O O - O - -      SIO                                 3A
   O - - O O O - O O -      Memory                              3B
   O - - O O O O - - -      CPU Board                           3C
   O - - O O O O - O -      System Bus                          3D
   O - - O O O O O - -      Apollo keyboard                     3E
   O - - O O O O O O -      Utility Chip                        3F

   S = Service Mode Indicator
   On = Service Mode, Not On = Normal Mode
   P = Power-OK Indicator

Mnemonic Debugger Level LED Status Codes

At the Mnemonic Debugger (MD) level, while the system is in Service mode, the front panel LEDs display system status codes. Table 5-13 lists the MS status LED codes and their meanings.

Table 5-13 MD Level LED Status Codes

   LED Display
   (E through H Flashing)   System Status                       Hex Code

   P A B C D E F G H S
   O - - - - O - - - -      Keyboard Wait Loop                  08
   O - - - - O O - - -      Waiting at MD Prompt                0C
   O - - - - - - O - -      Waiting for Disk                    02
   O - - - - - - O O -      Waiting for Network Transmit        03
   O - - - - - O - - -      Waiting for Volunteer Response      04
   O - - - - - O - O -      Waiting for Network Receive         05

   S = Service Mode Indicator
   On = Service Mode, Not On = Normal Mode
   P = Power-OK Indicator

The manual "HP Apollo 9000 Series 400 Model 425e, Domain/OS Owner's Guide" (Order No. A1499-90001, Part No. A1499-90604), contains rather similar info. On page 9-13 it has:
Table 9-12 LED Codes for FRUs

   LED Display              Field Replaceable Unit Name         Hex Code

   A B C D E F G H P
   - - - - O O - O O        Boot ROM                            0D
   - - - O - - - O O        EEPROM                              21
   - - - O O - - - O        DMA                                 28
   - - - O O O O - O        EEPROM                              2D
   - - O O - - - - O        SCSI Device 0                       30
   - - O O - - - O O        SCSI Device 1                       31
   - - O O - - O - O        SCSI Device 2                       32
   - - O O - - O O O        SCSI Device 3                       33
   - - O O - O - - O        SCSI Device 4                       34
   - - O O - O - O O        SCSI Device 5                       35
   - - O O - O O - O        SCSI Device 6                       36
   - - O O - O O O O        SCSI Device 7                       37
   - - O O O - O - O        SIO                                 3A
   - - O O O - O O O        Memory                              3B
   - - O O O O - - O        CPU Board                           3C
   - - O O O O - O O        System Bus                          3D
   - - O O O O O - O        Domain keyboard                     3E
   - - O O O O O O O        CPU Board (Utility)                 3F

   P = Power-OK Indicator

There seems to be some mistake in the codes or lights for 21 to 2D (the lights as shown correspond to codes 11, 18 and 1E).

(12/ 6/00, Paul Szabo <psz@maths.usyd.edu.au> )

[5.19] How can I test my Apollo for hardware problems?

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 it lists a directory which has DOMAIN_OS, your node has Domain/OS SR10. If it has AEGIS, your node has Aegis SR9 or below. If it says sysboot not found, your harddrive is okay, but no OS is installed. If it gives a disk error, it is either a faulty harddrive/controller, or perharps the drive is not formatted.

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.

(20/11/96, Nickolai Zeldovich <kolya@zepa.net> )

[5.20] Where can I find part numbers for Apollo boards?

Tame, Inc. [see below, THIRD PARTY VENDORS] has a list of some Apollo parts, although some things are not completely correct:

( 7/12/96, Tim Hunkler <hunkler@goodnet.com> )

[5.21] Where can I get some specs on Apollo ESDI drives?

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

and particularly ESDI Micropolis and ESDI Maxtor drives.

( 7/12/96, Tim Hunkler <hunkler@goodnet.com> )

[5.22] What about X-Bus terminators on DN10000's?

There is one 331/471 pack on the terminator which appears not to fail. The failure modes on the terminators appears to me to be on one set of the resistor packs. These are the seven 101/750G packs that are the prevalent packs on the terminator. These are 10 lead packs (SIP) and empirical tests give the following results on a "good" pack.

Dale 10C5-101/750G    (crude drawing)
            ---------------------
            |1 2 3 4 5 6 7 8 9 A|
            ---------------------
             | | | | | | | | | |

Pin to pin resistance:
      1   2   3   4   5   6   7   8   9   A
   1      a   a   a   a   a   a   a   a   c
   2  a       d   d   d   d   d   d   d   b
   3  a   d       d   d   d   d   d   d   b
   4  a   d   d       d   d   d   d   d   b
   5  a   d   d   d       d   d   d   d   b
   6  a   d   d   d   d       d   d   d   b
   7  a   d   d   d   d   d       d   d   b
   8  a   d   d   d   d   d   d       d   b
   9  a   d   d   d   d   d   d   d       b
   A  c   b   b   b   b   b   b   b   b  

      a = 47 ohms
      b = 50 ohms
      c = 22.1 ohms
      d = 85.7 ohms
  eg.  pin 1 to pin 3 measures 47 ohms
       pin 5 to pin 7 measures 85.7 ohms

On failing packs, the resistance varies from the above table, usually significantly. My theory is to replace those packs which fail and reuse the terminator boards. This theory has not been tested, but I did get Dale to produce some of the resistors in a custom order.

I have not proven this theory of DN10000 terminator repair, yet.

(14/7/98, James J. Waldram <waldram@grizzly.uwyo.edu> )

I have successfully repaired a couple of DN10000 X-bus terminators using resistor packs provided by Jim Waldram. It's a bit fiddly and I haven't yet found a way of getting the old packs out without destroying them, so I can't cannibalise dud terminators to repair others.

One thing I should add is that the circuit boards for the terminators seem fairly robust and will take quite a lot of pratting about with soldering irons and solder suckers.

( 7/3/99, Keith Harwood <keith@betor.DIALix.oz.au> )

[5.23] What CD-ROMs can be used in 400-series?

I think, you can add any SCSI-CDROM to 4xx. We use a SCSI-2 CD-ROM Plextor PX-63CS (as well as a DAT HP C1533A, both mounted into an external Box with separate power-supply) without any problems. At the moment it is connected to a 425t, but it was also hooked up to a 433s. (We still use four 4xx to do our daily engineering tasks - grown up on DN2000/ DN2500 with Domain/OS and UNIX, i love these machines, esp. DM, the unique network filesystem, NCS/DDS, ACLs, node owner policy, protected subsystems, etc., ... but back to the subject :-)

The 425s runs:

$ /com/bldt
Domain/OS kernel(11), revision 10.4.1.2, December 8, 1995  5:27:05 pm

with all Patches applied since SR10.4.1 starting with PD93_M0681. Patches can be downloaded for free from ftp://gvaweb7.net.external.hp.com/domain_patches/m68k.

The CD-ROM drive introduces itself as follows:

$ /systest/ssr_util/scsi_info
Target 1:
Device Type: Read-only DASD (Removable Media) 
Vendor: PLEXTOR
Product: CD-ROM PX-6XCS
Rev Level: 1.03
ANSI version compliance: SCSI-2
Features supported: Synchronous Data Xfer; Linked Commands; 

Here are some internal SCSI-2-drives from Plextor and Pioneer, which I found on the web (there are a lot of other vendors too):

http://www.plextor.com/product.htm, http://www.plextor.co.jp/erom/es_2.html:

20x speed:	Plextor PX-20TSi (Tray)
12x speed:	Plextor PX-12CSi (Caddy) or PX-12TSi (Tray)
12x speed:	Plextor PX-12CSi (Caddy) or PX-12TSi (Tray)
 8x speed:	Plextor PX-83CS  (Caddy)
 6x speed:	Plextor PX-63CS  (Caddy)

http://www.pioneer-eur.com/products/multimed/optical/cdsingl.htm:

15-32x speed:	Pioneer DR-32X   (Tray)    = DR-566  (OEM Version)
15-32x speed:	Pioneer DR-U06S  (Slot-in) = DR-506S (OEM Version)
12-24x speed:	Pioneer DR-24X   (Tray)    = DR-533  (OEM Version)
12-24x speed:	Pioneer DR-U03S  (Slot-in) = DR-503S (OEM Version)
12x speed:	Pioneer DR-U12X  (Tray)    = DR-466  (OEM Version)
10x speed:	Pioneer DR-U10X  (Tray)    = DR-433  (OEM Version)
4.4x speed:	Pioneer DR-U124X (Tray)
 4x speed:	Pioneer DR-U104X (Caddy)

It is rumoured, that the OEM version lacks audio grabbing functionality, but at the moment ;-) there is no support for this under DomainOS anyway.

I decided to buy the 6x speed plextor drive with caddy back in 1996, because the spec claimes support of High Sierra (HFS) and ISO9660 Format with Rock Ridge Extension as well as UNIX-compatibility ("512 byte per sector for workstation use" is advertized).

Maybe 512-Byte-Blocks are only neccessairy for native filesystems on bootable CD-ROMs, which HP didnt offer for Domain/OS - but for HP-UX, see /install/doc/apollo/os.v.10.4__notes:

<--- snip --->
3.6 Changes to HP Series 6100 Model 700/S CD-ROM User's Guide
<--- deleted --->
Table 1-2 shows the minimum Boot ROM revisions required if you want to boot software from the CD-ROM drive. Hewlett-Packard does not suport bootable systems on Domain, but certain third parties or Independant Software Vendors (ISVs) may provide bootable software on a CD-ROM disc. Use the information in Table 1-2 if you have a bootable CD-ROM disc from one of these vendors. Note that the CD-ROM drive can only boot to the systems that are listed in Table 1-2.
<--- snip --->
Unfortunately I have none of these Manuals to check Table 1-2:

A1999-90602     HP Series 6100 Model 700/S CD-ROM User's Guide (SR10.3)
A1999-90609     HP Series 6100 Model 700/S CD-ROM User's Guide (SR10.4)
A1999-90003     HP Series 6100 Model 700/S CD-ROM Drive Service Handbook

There are some drives with 2048 only and some others with 2048/512 bytes data block size available - so i recommend to look for the latter ones.

Plextor drives support HP-UX, so if you decide to install HP-UX on 4xx - but why should you? ;-) - you may be able to boot from those drives.

I am starting the daemons xpager and cdfsd (besides llbd and rpcd) at boot time at the machine whith the local CD-ROM drive as explained in the OS release notes /install/doc/apollo/os.v.10.4__notes, see chapter 1.4.3.1 Changes in CD-ROM Drive Usage at SR10.4 and 1.7.3 External Pager Daemon.

This is from my /etc/rc:

<--- snip --->
# xpager: external paging daemon (new at SR10.4)
# xpager interacts with the kernel and allows page faults on certain types of
# mapped objects to be handled via a user-space type manager.
# Currently, this mechanism is only used by cdfsd for accesses to CD-ROMs. (?)
# 8-) Stubfile: "/etc/daemons/xpager#" with #=1|2|...n enables xpager n times
XPAGERNR=0
if [ -x /etc/xpager -a -f /etc/daemons/xpager* ]; then
	XPAGERNR=`(cd /etc/daemons;/bin/ls xpager*|/com/chpat xpager)`
	/etc/xpager -m $XPAGERNR &
	(echo " xpager(x$XPAGERNR)\c" >/dev/console)
fi

# cdfsd: CDROM file system daemon. (High Sierra Group or ISO 9660 format)
# supports mount of a CDROM file system on this machine.
# requires xpager and llbd or rpcd running!
# 8-) Stubfile: "/etc/daemons/cdfsd" enables cdfsd
if [ -x /etc/cdfsd -a -f /etc/daemons/cdfsd \
	-a $LLBD_ENABLED = true -a $XPAGERNR != 0 ]; then
	(echo " cdfsd\c" >/dev/console)
	/etc/cdfsd &
<--- snip --->

As usual, the UNIX-mount/umount commands work for root only:

/etc/bsd4.3/mount -t cdfs /dev/cdrom_# /cdrom
/etc/sys5.3/mount -f cdfs[,0]

But we run DomainOS - so i enabled node owners protection policy:
$ /etc/lprotect -protect owners
and each user or group member with w-rights on `node_data/etc/node_owners (trust the user) can mount and unmount CDs - and the CD-filesystem is available through DDS as well as via NFS for non-Domain boxes. (try this with UNIX - on HP-UX i'm still wrestling with this RPC-based pfsd/pfs_mountd-stuff, remember patches PHCO_12652 and PHCO_15453 %-|)

I use the following shellscript for mounting and umounting:

#!/bin/ksh
# mount or unmount /dev/cdrom_1 on n99999 under /cdrom_1
# Note: /devl/cdrom is a link to //n99999/cdrom_1
# Usage: cdrom   ... toggles mount-state
CDHOST=n99999
CDDEVICE=/dev/cdrom_1
CDMNTPNT=/cdrom
CDSTUB=no_cd   
# go home to step out of the volume containing the mountpoint cd
# visibility of stubfile is decisive for mounting and unmounting the cdrom
if [ -f //$CDHOST/$CDMNTPNT/$CDSTUB ]
# mount
 then
  print "($0): mounting $CDDEVICE under $CDMNTPNT on $CDHOST ..."
  /etc/cdfsmount $CDDEVICE $CDMNTPNT
  /etc/cdmntsuppl -u $USER -g $PROJECT -F 0555 -D 0555 -l -m $CDMNTPNT
  /etc/cdmntsuppl $CDMNTPNT
  /usr/apollo/bin/cdvd $CDMNTPNT
# unmount
 else
  /etc/cdfsumount $CDDEVICE
  /com/ld $CDMNTPNT
  print "($0): Please remove Caddy from CD-ROM-Drive !"
fi
# return to the point, from wich this script was called
cd $OLDPWD
### EOF

Use the /etc/cdmntsuppl to set/get rights and ISO9660's RockRidge name conversion - UNIX-like is -l for upper-2-lowercase-conversion and removal of trailing dots without extensions and -m to suppress name;# version numbers.

If you are brave enough to code, read /usr/apollo/man/mana/cd_?*.a, than inlcude /apollo/include/cdrom.h and link against /$(SYSTYPE)/usr/lib/isp_m68k/libcdrom.a

(18/7/98, Jan Hoehne <Jan.Hoehne@nle2.kwu.siemens.de> )


[6.0] SALVAGING OLD APOLLOS

[6.1] Can I use an Apollo controller and monitor on a Windows PC? How about under XFree86 and Linux/NetBSD?

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: ftp://ftp.wfu.edu/usenet/apollo/doc/monitor-sync.ps or directly from the author: Tony <tony@ajfcal.cuc.ab.ca>.

Dan <root@juno106.demon.co.uk> reports that he got the circuit from monitor-sync.ps to work with his HP/Sony 98754A HiRes monitor. He says:

I built the circuit detailed and discovered after a lot of messing around that there is an error on the diagram!! The pinout on the 74LS02 is incorrect. Pins 2 and 3 are the NOR gate inputs and pin 1 is the output!

I used a 10K preset for the bias control.

Make sure you remember to connect pin 7 to ground on both chips and pin 14 to a clean 5 volt rail.

Having built the circuit make sure your PC is running in 1280 by 1024 with a NON INTERLACED frame rate of 60Hz. These monitors are very good quality - an equivalent would cost you a heck of a lot of money even thesedays but sadly the frame rate is just a little too low for a totally flicker free picture :-( - but still its very good!

[ Maintainer's note: Another solution is to buy a fixed frequency video card, sold by a number of vendors, such as Software Integrators, Inc., or Mirage (see section 7.1). ]

Are there any uses for anything else from an Apollo?

The Case/Power supply can be adapted to hold a PC in a relatively easy fashion.... If you have a desoldering machine; you may find a use for the memory chips on the cards... If you had a Disk then it could be potentially useful (either MFM or ESDI depending on the disk). The disk controllers are not useful... The ethernet cards are simply 3c505's with an Apollo boot prom which can be removed... The token ring cards are useless for non-apollo work as far as I can tell...

( 2/15/94, Herb Peyerl <hpeyerl@novatel.cuc.ab.ca> )

The 98751A is a Lo-res color, 1024 x 768, 47.7khz/60Hz. These monitors are fixed frequency, 47.7khz~50.5khz. I don't know of any PC brand graphics cards that support these monitors.

( 3/25/94, Steven Gaudet <sjg@world.std.com> )

I have a 98751A HP/Apollo monitor and it works well in Windows using a card called "PCI-48". It's got the TSENG ET4000 chip set on it. I bought it with the monitor from Data Station. My understanding it that it was custom built card to drive this fixed frequency montior.

( 1/14/97, Jim Kownacki <kanak@telerama.lm.com> )

I don't know much about VGA, but I thought that you just selected a pixel clock from some small set of available clocks that usually run from 28 MHz on up to 85 or so, then you could set the length of scan lines and sync pulses to any number of pixel clocks. That would imply that you can use any monitor at all, within limits, as long as you know the timings it will sync to. Exact timings are available in the monitor-info file in the apollo archives at archive.umich.edu. The 1024x800 color monitor has a horizontal display interval of about 15 usec, so that means a pixel clock around 70 MHz.

You would have to combine the sync somehow, since the Apollo monitors want it composite with video on the green channel, and VGA supplies it separately, but that should be easy to do with a few diodes and maybe a transistor or two.

( 3/25/94, Jim Rees <Jim.Rees@umich.edu> )

I still have not succeeeded in finding a card supported by XFree86 that will work with the Apollo 1280x1024 color monitors, but I did get some information recently that might be of assistance to people (hopefully the next version of XFree86 will be usable).

The 1280x1024x8 graphics card can be used in a PC with Windows 3.1.

Specifically, the Apollo card is a special version of the Matrox PG-1281 called the PG-1281/AP. I called Matrox and one of the technical folks there told me that the standard PG-1281 Windows 3.1 drivers should work, but it would need a special parameter file with the video parameters. He created the files for me, and this morning I was able to get the card and monitor running in a PC. I wouldn't say the card is particulary fast, but it definitely does work as a second monitor for Windows on a PC that has a monochrome display. If anyone else wants to do this, I'm sure I can pass along the information and code, since the drivers were available for public download.

( 7/28/94, Leonard N. Zubkoff <lnz@dandelion.com> )

[ Maintainer's note: The drivers are available by anonymous FTP from ftp://archive.umich.edu under the file 'pg1281ap.zip' ]

> I'm attempting to run an Apollo color 1280x1024 monitor off my PC using
> XFree.  I've got the hardware connection fairly stable, but am having
> problems with setting up an XFree video mode.

This monitor is a Matsushita J2P36X. To drive it at 1280x1024 you'll need a dot clock of 125 MHz. If your VGA card won't do this, you may have to tear into the monitor's sweep circuitry, since it's not a multi-sync design.

Here are the timing numbers you'll need for your Xconfig file. If you get this to work, please send me your Xconfig.

Pixel rate - 124.996 MHz
Pixel period - 8.000256 nsec.
Aspect Ration 5/4
Horizontally displayed pixels - 1280
Vertically displayed lines - 1024
Horizontal frequency - 73.702 kHz
Horizontal period - 13.568 usec., pixels 1696
Horizontal front porch - 0.256 usec., pixels 32
Horizontal sync - 1.536 usec., pixels 192
Horizontal back porch - 1.536 usec., pixels 192
Horizontal blanking - 3.328 usec., pixels 416
Horizontal display area - 10.240 usec., pixels 1280
Vertical fields per frame (noninterlaced) - 1
Vertical field frequency - 68.24 Hz
Vertical field period - 68.24 msec, lines 1080
Vertical front porch - 40.7 usec, lines 3
Vertical sync - 40.7 usec, lines 3
Vertical back porch - 678 usec., lines 50
Vertical blanking - 759 usec, lines 56
Vertical display area - 13.893 msec, lines 1024

( 9/19/94, Dan Waugh <dwaugh@bnr.ca>, Jim Rees <Jim.Rees@umich.edu> )

There are actually two versions of this monitor, one with a 68Hz vertical refresh rate and the other with 70Hz. Here are Xconfig mode lines for both of them (these have been tested with my STB Pegasus VL):

    # Apollo 010700-005 1280x1024 Color Display
    "1280x1024-68" 124.996  1280 1312 1504 1696   1024 1027 1030 1080
    "1280x1024-70" 124.996  1280 1312 1472 1664   1024 1027 1030 1072

In order to use one of these monitors with XFree86, you'll need a graphics card that supports the 125MHz pixel clock as well as providing RGB outputs with sync-on-green.

( 9/22/94, Leonard N. Zubkoff <lnz@dandelion.com> )

[6.2] Can I connect an old ESDI drive to a SCSI interface?

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.

( 2/15/94, Willem Jan Withagen <wjw@ebh.eb.ele.tue.nl> )

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.

( 2/15/94, David Lacey, M.D. <David-Lacey@uiowa.edu> )

[6.3] Can I use old ESDI drives on PC's?

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?

( 2/15/94, Steve Levesque <levesque@galaxy.mpr.ca> )

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.......

( 2/15/94, Tom Wowianko <wowianko@aa.ab.com> )

[6.4] What can I do with an old SMS-Omti hard disk controller? What about a WD7000V-ASE or a WD7000-ASC?

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.

( 6/3/93, Andrew F Gunnesch <afgun@engin.umich.edu> )

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.

( 6/3/93, Steve Swamp <swamp@bnr.ca> )

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.

( 7/26/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

[6.5] Can I convert my Apollo into an X-terminal?

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: ftp://ftp.wfu.edu/usenet/apollo/doc/apollo-as-xterm

( 8/5/94, Russell Ayling <rayling@rta.nsw.gov.au> )

[6.6] Can I run a different operating system (HPUX, BSD, etc) on my Apollo?

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.

(7/26/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

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.

( 7/26/94, Hung Do <do@dolabela.css.beckman.com> )

[6.7] Can I use the Apollo keyboard on another computer?

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

( 7/28/94, David Stonehouse <dstone@xpress.MITRE.org> )

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

( 7/28/94, Dan Bennet <dan@hpwina39.uksr.hp.com> )

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.)

(11/20/96, Nickolai Zeldovich <kolya@zepa.net> )


[7.0] THIRD-PARTY VENDORS

[7.1] Is there a list of third-party component vendors?

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

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

AnDATAco Computer Peripherals
9550 Waples Street
San Diego, CA 92121
(619) 453-9191
http://www.andataco.com/

Infotek Systems
1045 S. East Street
Anaheim, CA 92805
(714) 956-9300

Martech
1151 West Valley Boulevard
Alhambra, CA 91803
(818) 281-3555

Digital Micronics, Inc
5674 El Camino Real, Suite P
Carlsbad, CA 92008
(619) 931-8554

MDL Corporation
15301 NE 90th St., Redmond, WA 98052
(206) 861-6700
(206) 861-6767 FAX
http://www.mdlcorp.com/

R Squared
11211 E. Arapahoe Road, Suite 200
Englewood, CO 80112
(800) 777-3478

Mesa Tech
267 Boston Rd.; Suite 13
Billerica, MA 01862
ATTN: Michael Hall
(508) 663-8254

MESA Tech: corporate office
9720 Patuxent Woods Drive
Columbia, MD 21046
(301) 290-8150

CMI Inc.
85 Flagship Dr.
North Andover, MA 01845
800-497-4264
508-687-3700
http://www.cmiinc.com/

Tame, Inc.
1245 Birchwood Dr.
Sunnyvale, CA 94089
(408) 734-3091
(408) 734-4279 FAX
http://www.tame.com/

Computer Locators Int'l, Inc.
840 U.S. Highway 1 - Suite 110
North Palm Beach, FL 33408
(561) 627-7797
(561) 624-2708 FAX
E-mail: JRosow@aol.com

Software Integrators Inc.
51 Evergreen Drive
Suite A
Bozeman, MT 59715
(800)-547-2349
(406)-586-4987
http://www.si87.com/

Mirage Video Solutions
Customer Service & Technical Dept.
9750 South La Cienega Blvd.
Inglewood, CA 90301
(800)-228-3349 ext 151
http://www.mirage-mmc.com/
E-mail: info@mirage-mmc.com

Datagate, Inc
6490 S McCarran Blvd Suite B14
Reno, NV 89509
702-882-1313 (FAX 702-882-1689)
http://www.datagateinc.com/

MV Technical Sales
1969 Kellogg Ave
Carlsbad, CA 92008
http://www.mvts.com/

Alante' Corporation
1156 York Lane
St. Helena, CA 94574
707-967-4100 (FAX 707-967-4101)
http://www.alante.com/

[7.2] Are there third-party vendors of ethernet boards? Where can I get an ethernet card for my Apollo?

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: ftp://ftp.wfu.edu/usenet/apollo/doc/ether-switches.

( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

I bought a 3C505 board from 3Com instead of Apollo because I'm not interested in doing diskless booting over the ethernet. I know it's missing a prom for doing that. I've set the jumpers as described in the /systest/ssr_util/jumpers program with no luck.

( 2/15/94, Bryan Province <bep@quintro.uucp> )

Correct settings are port 300, mem addr 80000, dma 6, intr 10, test mode off, rom select off. If Domain/OS (and DEX) can't find the board at all, you've probably got the port wrong. You should have jumpers 8 and 9 in, where "in" is away from the back panel bnc and aui connectors.

A second board would go at port 310, mem addr 84000, dma 3, intr 9.

( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )

Correct, however all the original poster said was that self tests couldn't find the board. I'm assuming that he's referring to the self tests that run when powering up in normal mode (or when the appropriate prom command is it "te" ?) is entered. If this is the ONLY time the board can't be found, it's because of the lack of the boot prom (self test code is stored in there). Run "ex config" and remove it's knowledge of the ethernet board so it won't try to test it. The OS should find it ok (and nothing was said in the original mail about whether the OS could or could not find it, I assume that it could (it should!) ).

( 2/15/94, Carl Heinzl <carl@Cayman.COM> )

We [MV Technical Sales] sell the ethernet adapter for the Apollo DNXXXX series machines with the proper boot prom and everything. I'm the one that bought stock 3C505 cards and dup'd the PROM off an existing card and programmed it onto a new prom for the stock cards. They work great.

[ See section 7.1 for the address ]

(12/14/99, Joe Avila <JoeA@mvts.com> )

[7.3] Where can I go besides HP for repairs?

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.

( 2/15/94, Mike Thomas <honeywel@chama.eece.unm.edu> )


[8.0] MISCELLANY

[8.1] What are the internal names/SAU numbers for the various node types?

  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)

( 2/15/94, Nat Mishkin <mishkin@apollo.hp.com> )

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.

(11/20/96, Nickolai Zeldovich <kolya@zepa.net> )

[8.2] Any funny Status codes and background info?

% 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.

( 2/15/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )

Contributors

Each question is accompanied by a list of people who have helped with the answer. We've also dated each Q&A to reflect the last time it was updated. If you have contributed but feel left out or know of someone else who has contributed, please bounce us a piece of mail so that we may give proper credits.

End of Apollo FAQ