[1.0] GENERAL QUESTIONS

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

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

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

"Using the HP SupportLine mail service, you can:

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

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

[2.0] USER AND ENVIRONMENT

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

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

( 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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

Nice, but not necessary.

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

You can go about this in either of 2 ways:

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

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

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

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

The easy way:

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

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

The advantages of version 2 over version 1 are:

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

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

So you might choose the hard way:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Place the node into service mode, by switching the NORMAL/SERVICE mode switch on the back of the machine (for DN[345]xxx style nodes) into SERVICE mode (down position). This should cause the machine to come up with an MD prompt ( > ) when turned on. Hit RETURN a few times until you get a message telling you the version of MD, and another prompt, at which you can type.
• Boot the node using:

      > DI W
      > EX DOMAIN_OS
  

• When you get to the ) prompt, do:

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

• If you get an error message saying "not enough rights" or something to that extent, the ACLs on your machine have been changed from the default Domain/OS installation, and obtaining access to your system will likely have to involve another Apollo node on your network that you have access to, or a reinstall of Domain/OS.
• Now your registry is empty. Boot the machine using

      )go
  

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

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

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

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

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

      $ /install/init_master_rgy
  

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

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

  Or, using interactive mode:

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

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

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

[5.0] SYSTEM RELATED HARDWARE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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