NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/apollo/3459

Internet Message Format | 1992-09-03 | 70.2 KB

Xref: sparky comp.sys.apollo:3459 news.answers:2786
Path: sparky!uunet!mcsun!sun4nl!tuegate.tue.nl!eba!ebh!wjw
From: [e-mail] (Willem Jan Withagen)
Newsgroups: comp.sys.apollo,news.answers
Subject: comp.sys.apollo FAQ (september)
Message-ID: <[e-mail]>
Date: 1 Sep 92 09:17:14 GMT
Expires: 1 Dec 92 01:01:01 GMT
Sender: [e-mail] (The News system)
Organization: Eindhoven University of Technology, The Netherlands
Lines: 1877
Approved: [e-mail]
Suppersedes: <[e-mail]>

This is the Apollo Frequently Asked Questions file.  I compiled it from
various sources.

As of 25 march 92 this file is maintained by Willem Jan Withagen.
You can mail possible items to add to the file to:
    [e-mail]

    Willem Jan Withagen,
    Eindhoven University of Technology,
    The Netherlands.

Topics:

 1 )  Is there an archive of comp.sys.apollo?
 2 )  Where can I get "foo" for my Apollo (for all values of "foo"
      where "foo" is some freely available software package)?
 3 )  Would anyone have a termcap entry that will work correctly with
      the VI editor?
 4 )  Why is X so slow at sr10.2?
 5 )  Why do I get these errors when I try to compile an X application?
 6 )  Where can I get x11r4?
 7 )  A list of third-party component vendors.
 8 )  Where can I get a version of sendmail which supports MX records?
 9 )  "does this or that version of sendmail work on apollos?"
 10)  What is "unknown mailer error 1?"
 11)  How can I use the DM editor for mail or while su'd?
 12)  How can I keep my node clocks synchronized?
 13)  When I try to use NFS on my IBM PC to access files on my
      Apollo, it complains about not finding an "Authentication Server."
 14)  Why doesn't Apollo ftpd support anonymous ftp?
 15)  How can I get auto word-wrapping in the DM?
 16)  How can I connect my Macs to my Apollo in a reasonable way?
 17)  Are the VT100 PF1-PF4 keys defined in the Apollo version of xterm?
 18)  What else should I know about X keysyms?
 19)  Where can I get emacs?
 20)  Do you have a problem with Gnu Emacs' C-x` command?
 21)  Does anybody know where I can get proxy ARP?
 22)  Are there third-party vendors of ethernet boards?
 23)  How do I enable IP name service?
 24)  Why can't I log in as root anywhere except a DM pad?
 25)  How can I determine the load average without /dev/kmem?
 26)  Why do I get "cannot start daemon" when I try to use lpr?
 27)  How can I get my printer to work?
 28)  Do I need to buy Omniback to use my Exabyte 8mm tape drive?
 29)  How can I read cartridges written on SUN systems?
 30)  Does anyone out there know about using DAT drives for backing up Apollos?
 31)  How do I use wbak to write stdout to a SUN workstation's tape?
 32)  Why does routed not work for long periods of time under SR10.2?
 33)  Does Apollo NFS work?
 34)  How can I get gcc and g++ to run?
 35)  Where can I get an assembler?
 36)  What's the story on adding more disks to my node?
 37)  I'm trying to get a SCSI-2 type disk to work with my Apollo but it
      does seem to work. What did I do wrong?
 38)  What are the connections in a 3-way serial porst splitter.
 39)  Why do I get:
         Unable to go into maintenance state  User not authorized to
         perform operation (network computing system/Registry Server)
 40)  Fixing your 19" monochrome monitor.
 41)  How well does SLIP work?
 42)  What are the internal names for the various node types?
 43)  Where else can I go besides HP for repairs?
 44)  How do I find out about, and fix, bad spots on my disk?
 45)  Why does my dn10000 ethernet interface stop working?
 46)  Has anyone else experienced power-supply problems with their
      Apollo 10000.
 47)  Former maintainer
 48)  Contributers






===============

 1 )     Is there an archive of comp.sys.apollo?

Answer:

There is an archive and an info server at the Eindhoven University of
Technology, maintained by Willem Jan Withagen <[e-mail]>.  To
try it out, telnet to apoinfo.eb.ele.tue.nl on port 3401 from a vt100 or
equivalent.  From your Apollo, for example, start up an xterm or vt100 and
run "telnet apoinfo.eb.ele.tue.nl 3401" .

An archive of the comp.sys.apollo newsgroup is maintained by Jim Richardson
([e-mail]) and is available by anonymous FTP from maths.su.oz.au
(129.78.68.2).

The file README.FIRST in directory comp.sys.apollo gives details of the organ-
ization of the archive, which goes back to November 1989.

There are index files, which contain the following fields from each article:

    From        Subject        Summary        Keywords
    Message-ID    References    Date

These indices should be useful to people wanting to search through the wealth
of information in the archive for answers to questions that have been discussed
in the newsgroup in the past.

===============

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

Answer:

Many things are available by anonymous ftp over the Internet.  Check the
"Anon-FTP-sites" file on archive.umich.edu.  A good place to find Apollo
specific code is
         the ADUS archive at adus.ecn.uiowa.edu.
Also try
         archive.umich.edu,
         hpcvaaz.cv.hp.com,
         maths.su.oz.au,
     and ftp.eb.ele.tue.nl.

===============

 3 )  Would anyone have a termcap entry that will work correctly with
      the VI editor?

Answer:  Nope.  You have to use the vt100 emulator (which ought to get 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.

===============

 4 )  Why is X so slow at sr10.2?

Answer:
    You need to install "psk5".  This should be available from your friendly
    HP/Apollo sales office.  It's fixed in sr10.3.

===============

 5 )  Why do I get these errors when I try to compile an X application?

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

Answer:

Your application was written for X11r4, and your Apollo only has X11r3.
Even though r5 is out now, HP still only fully supports r3 -- that puts them
two revs behind.


===============

 6 )  Where can I get x11r4?

Answer:

Your r4 clients will work just fine with the Apollo share-mode r3 X server.
The psk_q3_91 from Apollo includes some r4 client libraries (but not Xaw,
the Athena widgets) and a server that runs simultaneously with the DM, but
rather than sharing the screen, you switch between them with a hot key.  You
can get this by anonymous ftp from hpcvaaz.cv.hp.com, in the directory
~ftp/pub/apollo/pskq3_91 .  You can get shared r4 client libraries in binary
form by ftp from archive.umich.edu.  You can get x11r4 sources from the
following sites:

                        Machine                  Internet      FTP
    Location            Name                     Address       Directory
    --------            -------                  --------      -------------
(1) West USA            gatekeeper.dec.com       16.1.0.2      pub/X11/R4
    Central USA         mordred.cs.purdue.edu    128.10.2.2    pub/X11/R4
(2) Central USA         giza.cis.ohio-state.edu  128.146.8.61  pub/X.V11R4
    Southeast USA       uunet.uu.net             192.48.96.2   X/R4
(3) Northeast USA       crl.dec.com              192.58.206.2  pub/X11/R4
(4) UK Janet            src.doc.ic.ac.uk         129.31.81.36  X.V11R4
    UK niftp            uk.ac.ic.doc.src                       <XV11R4>
(5) Australia           munnari.oz.au            128.250.1.21  X.V11/R4


===============

 7 ) A list of third-party component vendors.

I am looking for addresses for Apollo third-party vendors for disk
and memory (DNxxxxx's, PRISM, and 400 series). Anyone have a list of
addresses? Any info would be appreciated.

Answer:

======================================================================
DISCLAIMER:  I will neither vouch for, nor complain about, any of the
following companies.  I have never worked for any of them, nor am I
receiving any favoritism from them.  To the best of my knowledge, the
products listed are available from them, but it is not necessarily a
COMPLETE list of products -- please call them yourself.
The vendors listed are not in any particular order.  I typed them as
their addresses came up in my folders.
The last three companies _appear_ to be HP suppliers primarily.  If
this is true, I would expect them to deal mainly in the 9000 series
peripherals.  (However -- again -- call them).

John Thompson (jt)
Honeywell, SSEC
Plymouth, MN  55441
[e-mail]

======================================================================

National Peripherals, Inc
1111 Pasquinelli Drive, Suite 400
Westmont, IL  60559
[phone]
==> DNxxxx memory
==> 9000/400 series memory, I believe
==> Maxtor 8760E (697MB) disk drives
==> SCSI drives for 9000/400 series
==> Exabyte 8mm tape drives
==> other disk drives, etc.


North Central Peripherals
14041 Burnhaven Drive, Suite 114
Burnsville, MN  55337
[phone]
==> DNxxxx memory
==> 9000/400 series memory
==> Maxtor 8760E (697MB) disk drives
==> Exabyte 8mm tape drives
==> other disk drives, etc.

AnDATAco Computer Peripherals
9550 Waples Street
San Diego, CA  92121
[phone]
==> DNxxxx memory
==> Maxtor 8760E (697MB) disk drives
==> Exabyte 8mm tape drives
==> other disk drives, etc.

Infotek Systems
1045 S. East Street
Anaheim, CA  92805
[phone]
==> 9000/400 series memory

Martech
1151 West Valley Boulevard
Alhambra, CA  91803
[phone]
==> 9000/400 series memory

Digital Micronics, Inc
5674 El Camino Real, Suite P
Carlsbad, CA  92008
[phone]
==> 9000/400 series memory

 -- John Thompson (jt)
    Honeywell, SSEC
    Plymouth, MN  55441
    [e-mail]

Also:

Here are the names/addresses of two third party vendors that I have had
good luck with.

   local office                       corporate
   Mesa Tech                          MESA Tech
   267 Boston Rd.; Suite 13           9720 Patuxent Woods Drive
   Billerica, MA  01862               Columbia, Maryland 21046
   ATN: Michael Hall                  301-290-8150
        508-663-8254
   ==> HP SCSI drives for 9000/400 series
   ==> Exabyte 8mm tape drives
   ==> other disk drives, etc.

   Clearpoint Research
   35 Parkwood Dr
   Hopkinton Ma 01748
   508-435-2000
   800-877-7519 (New England)
   ==> DNxxxx memory
   ==> 9000/400 series memory

 -- Greg Rocco
    MIT Lincoln Lab
    [e-mail]


===============

 8 )  Where can I get a version of sendmail which supports MX records?

Answer:

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

 -- Jim Richardson

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

 -- [e-mail] (Ian Hoyle)

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

 -- Jim Rees


===============

 9 ) "does this or that version of sendmail work on apollos?"

     the questioncan be rephrased:
         "does this version of apollo work under sendmail?"

Answer:

are there sites out there that deliver or queue 8,000 - 10,000 messages
a day on/through their 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.

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

 -- [e-mail] (Paul Killey)


===============

 10)  What is "unknown mailer error 1?"

Answer:

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.

 -- Jim Rees

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.

 -- [e-mail] (Bruce Orchard)


===============

 11) How can I use the DM editor for mail or while su'd?

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


===============

Question:  Why won't kermit compile (or run) on my Apollo?

Answer:  There are some very old versions of kermit that have #ifdefs for
Apollo in them.  These are no longer necessary with Domain/OS (they were
needed for previous versions of Aegis with Domain/IX).  Get the standard
Unix kermit and use that.  I recommend the one on cuvmb.cc.columbia.edu.


===============

 12)  How can I keep my node clocks synchronized?

Answer:

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.

 -- Jim Rees

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.

Best regards, Annegret
--
 Annegret Liebers, Technische Universitaet Berlin, FB 3 (Mathematik), MA 6-1,
           Strasse des 17. Juni 136, W - 1000 Berlin 12, Germany
                       Tel:  +49 - 30 - 314 - 25791
                 email:  [e-mail]


===============

 13)  When I try to use NFS on my IBM PC to access files on my
      Apollo, it complains about not finding an "Authentication Server."

Answer:

Like always: There's an easy one, and a hard one.

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

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

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

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.

 -- [e-mail] (Willem Jan Withagen)


===============

 14)  Why doesn't Apollo ftpd support anonymous ftp?

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


===============

 15)  How can I get auto word-wrapping in the DM?

Answer:

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

 -- [e-mail] (Fred Stluka)


===============

 16)  How can I connect my Macs to my Apollo in a reasonable way?

Answer:  See the file mac-apollo (separate file because of its length).

 -- Carlton B. Hommel <[e-mail]>


===============

 17)  Are the VT100 PF1-PF4 keys defined in the Apollo version of xterm?

If so,where are they?  If not, can someone give me a hint how to define
them (or how to redefine any key for that matter).

 -- John A. Breen

Answer:

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.

 -- [e-mail] (Walt Weber)


===============

 18)  What else should I know about X keysyms?

Answer:

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 \
    <KeyPress>UpBox       : scroll-back(1,halfpage) \n \
    <KeyPress>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

 -- Jim Rees


===============

 19)  Where can I get emacs?

Answer:

A new version of my modifications to GNU Emacs for the Apollo is now available.
This version supports GNU Emacs 18.57, Domain/OS SR10.2 and SR10.3, and the
latest release of the Domain C Compiler...

I am distributing this release from labrea.stanford.edu (36.8.0.47).  The
following files are available for anonymous ftp from the "pub/gnu" directory:

    APOLLO.README            README for Apollo GNU Emacs
    apollo-emacs.tar.Z        Apollo GNU Emacs modifications

As always, to install my Apollo GNU Emacs modifications, uncompress and untar
"apollo-emacs.tar.Z" on top of a unmodified GNU Emacs 18.57 distribution tree,
and consult "APOLLO.README" for building instructions.

Note: There is a bug in SR10.2 tar such that overwritten files are not
necessarily truncated to the proper size.  Before you untar the file under
SR10.2, execute the following commands:

rm README etc/APOLLO etc/MACHINES info/dir lisp/cl-indent.el* lisp/info.el*
rm lisp/lisp-mode.el* lisp/paths.el* lisp/rmail.el* lisp/rnews.el*
rm lisp/server.el* lisp/shell.el* lisp/startup.el* src/Makefile src/crt0.c
rm src/dired.c src/dispnew.c src/emacs.c src/fileio.c src/fns.c src/keyboard.c
rm src/m-apollo.h src/process.c src/sysdep.c src/x11fns.c src/x11term.c
rm src/xdisp.c src/ymakefile

                Leonard N. Zubkoff
        Lucid, Incorporated


Also, if you want a multi-window X version of emacs, check out epoch,
available from cs.uiuc.edu.  - Jim Rees


===============

 20)  Do you have a problem with Gnu Emacs' C-x` command?

Gnu Emacs 18.55 (with Leonard N. Zubkoff's patches for sr 10.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!

 -- [e-mail] (Michael K. Gschwind)

Answer:

This should probably go in some kind of FAQ list (sigh)...  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

 --


===============

 21)  Does anybody know where I can get proxy ARP?

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


===============

 22)  Are there third-party vendors of ethernet boards?

Answer:

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.

 -- Jim Rees

And as followup:
In article <[e-mail]>, [e-mail] (Bryan Province) writes:

  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.

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.

 -- Jim Rees

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

I tried emailing the original poster but couldn't for some reason...

 [e-mail] (Carl Heinzl)


===============

 23)  How do I enable IP name service?

Answer:

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

 -- Jim Rees


===============

 24)  Why can't I log in as root anywhere except a DM pad?

Answer:

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

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

 -- [e-mail] (Jinfu Chen)


===============

 25)  How can I determine the load average without /dev/kmem?

Answer:

getla()
{
    long avenrun[3];

    proc1_$get_loadav(avenrun);
}

 -- Jim Rees


===============

 26)  Why do I get "cannot start daemon" when I try to use lpr?

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

 [e-mail] (David Todd)


===============

 27)  How can I get my printer to work?

Answer:  It's not as easy as it should be.  See the separate file "printing."


===============

 28)  Do I need to buy Omniback to use my Exabyte 8mm tape drive?

Answer:

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.

 -- David Krowitz <[e-mail]>

===============

 29)  How can I read cartridges written on SUN systems?

Answer:
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.
--------
Since then, newer suns support still another (higher density) QIC 150
format.  However they still support QIC 24, which is the only format
supported on the Apollos.
--
Harald Hanche-Olsen <[e-mail]>               I eat my peas with honey
Division of mathematical sciences                      I've done it all my life
The Norwegian Institute of Technology             It makes the peas taste funny
N-7034 Trondheim NORWAY                          But it keeps them on the knife

From: [e-mail] (David Krowitz)
Subject: Re:  Apollo <--> Sun tapes?

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.

== Dave

===============

 30)  Does anyone out there know about using DAT drives for backing up Apollos?

I'm thinking of buying one to put on either a 425t or a DN4500 with Western
Digital SCSI

Answers:
Yes, 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.

Paul Szabo - System Manager   //        School of Mathematics and Statistics
[e-mail]        //   University of Sydney, NSW 2006, Australia

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'r realy interested). We used it on a 425 with SCSI.

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

Frank Teusink
[e-mail]

===============

 31)  How do I use wbak to write stdout to a SUN workstation's tape?

Answer:

I currently rsh to the target machine and run a csh script similar to
the following:

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

Oh yes. I currently run SunOS 4.1.2 and SR 10.2.1.

[e-mail]

===============

 32)  Why does routed not work for long periods of time under SR10.2?

Answer:

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.

        o 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 there-
          fore 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.

 -- [e-mail] (Eric Bratton)


===============

 33)  Does Apollo NFS work?

Answer: not always.  The most reliable NFS released so far (as of 3/91) is
NFS 2.1 plus patch 186.  This patch is not on the new patch tapes, so
you must ask for the patch explicitly when calling Apollo Customer Support.

 -- [e-mail] (Eric Bratton)


===============

 34)  How can I get gcc and g++ to run?

Answer:

Changes required to build gcc 1.37.1, g++ 1.37.1, and libg++ 1.37.0
for Apollo 68K platforms are now available. The changes are in the
form of compressed tar files containing new versions of files to
replace those from the virgin FSF distributions.

The following files are available via anonymous ftp from
labrea.stanford.edu (36.8.0.47) in the pub/gnu directory:

    APOLLO-GCC-README        4197 bytes
    APOLLO-G++-README        6379 bytes
    APOLLO-LIBG++-README        5906 bytes
    apollo-gcc-1.37.1.tar.Z          255509 bytes
    apollo-g++-1.37.1.tar.Z       418879 bytes
    apollo-libg++-1.37.0.tar.Z     43532 bytes

The README files explain what is involved in building each component.
Gcc must be built and installed in order to build g++, which must be
built and installed in order to build libg++.  The README files are
also included in the tar packages, but are available separately in
case you want to see what's involved first.

The gcc-1.37.1 changes fix several problems which were reported to me
by folks who tried my earlier gcc-1.37 changes. Also, you'll need the
gcc-1.37.1 changes in order to get g++ built, even if you already have
gcc 1.37 running.

I have only tried out these changes on SR10.2/SR10.3, using the
6.7/6.8 versions of the Apollo C compiler. There may be problems with
earlier releases of Domain/OS and the C compiler.

If you do not have ftp access, I can mail you the changes in the form
of diffs. If you request them, be sure to give me a voice phone number
so I can contact you in case I can't send you mail; I've had several
requests in the past from people I can't contact.


John Vasta                Hewlett-Packard Apollo Systems Division
[e-mail]       M.S. CHR-03-DW
[phone] x5978      300 Apollo Drive, Chelmsford, MA 01824
UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta

Answer:

I've done a port using a different approach.  You compile a version of
gcc using the standard Apollo compiler to generate a generic M68020
compiled code that follows Apollo calling conventions.  The output file
format is the "standard" GNU/FSF a.out format.  This is all done using
the "standard" configuration capabilities of the distributed gcc package.

I then have a separate "gnu2coff" program that transforms that file into
something acceptable to the standard Apollo linker.  "gnu2coff"
recognizes calls to functions in the normal Apollo shared libraries,
and automatically patches the code to call them correctly, so that
text segments can be left "pure" (read only).  It also handles
data references to shared library variables.  And finally it also
recognizes G++ compiled code, and automatically adds patches to get
static constructors/destructors run.

"gnu2coff" is called using shell files that run the appropriate
compiler front-ends, run "gnu2coff", and then run the Apollo linker.

In general "gnu2coff" is not able to handle symbolic debug info in
the "a.out" file, nor is it able to generate Apollo COFF format
symbolic debugging info.  (I once made a start at doing this, (and
that code still exists), but it was never complete, probably uses
the wrong approach, definitely is buggy, etc.)

So far gcc seems to run fine.  G++ compiles fine and all the small
tests I try run fine.  I "think" I have Libg++ ported correctly.
It all compiles fine, and some tests work.  However many other
tests don't work.  (Typically the default "new" handler in gnulib
ends up being called, which aborts.).  You need a working libg++
to try to port groff.

A version of "gnu2coff" was distributed on comp.sys.apollo a few
years ago.  The only real differences between that and my current
version is that floating point has a reasonable chance to be handled
correctly, and minor updates to be compatible with the latest
releases of gcc/g++.

 -- [e-mail] (Dave Clemans)

In article <[e-mail]>, [e-mail] (Michael J McNeill) writes:
=> Could somone please mail me the whereabouts of patches (I seem to
=> remember them being posted to this newsgroup some time ago) for
=> gcc-2.1 on Apollo68k machines.
=>
Hello!
I got (from ftp.gnu.ai.mit.edu and labrea.Stanford.EDU)
the Files:
 gcc-2.1.tar.Z
 gas-1.38.1.tar.Z
 bison-1.16.tar.Z
 patch-2.0.12u6.tar.Z
 apollo-gas-1.38.1.diffs.Z
 gcc-2.1.patch
and compiled gcc.
gcc works for short programs but I did no tests with large programs.

I had (using motif) the problem that my cpp had not enough memory
so I used /bin/cc -Yp,/usr/local/lib/gcc-lib/m68k-apollo-bsd/2.1, this
worked!

I am using Domain/OS 10.3.5 .
Hope this helps you!
--
Peter Kutschera


===============

 35)  Where can I get an assembler?

Answer:

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


===============

 36)  What's the story on adding more disks to my node?

Answer:

You can't add SCSI devices to the DN3x00 / DN4x00 / DN5x00 series machines,
unless HP/Apollo has made a _RADICAL_ change of policy.  I know that Mentor
(and probably 3rd party) has a SCSI board that sits in the AT-bus, and you
can access it if you use the special driver that's provided, but that will
NOT give you disk services.

The best (biggest) you can do with a DN3000 is a 325MB drive (Maxtor?).  If
you get a motherboard up-rev (to God knows what revision), the DN3500/
4000/4500 can take the WD7000 controller, which has a SCSI bus on it.
However, you can only hook up SCSI tape drives, floppies, and CD-ROMs as
far as I know.  The best (biggest) drive you can hang off a WD7000 is the
Maxtor 760MB ESDI drive (Maxtor XT8760E), which'll give you 650MB formatted
space.  You can put 2 drives per controller, and 2  controllers per node,
for 2.6GB of space.  I think you'll find that the up-revs you'll need will
be too pricey though.  Probably better to go with a 9000/400 series node
(maybe the 425E, if you have ethernet).  You can hang about 9 GB of SCSI off
of a 'E' or 'T' type 400 series, and 27 GB from an 'S' type 400 series (3
SCSI controllers, 6 SCSI drives per, 1.5 GB per).

John Thompson
Honeywell, SSEC
Plymouth, MN  55441
[e-mail]

And again in another message:

> I've read the faq, but it doesn't make the answer to this question entirely
> clear.  Can I connect an external SCSI disk to a DN5500 with a WD7000
> controller?  If so, is there any limitation on the size (eg 1.2GB)?  Is the
> process for involing etc.. the same as for a 425t?

OK -- let's make it clear then.

You can not hook up any SCSI disk drives to a WD7000 controller.  In fact, you
can't use SCSI drives on any Apollo machine except the DN2500 (the 9000/4xx is
an HP/Apollo box).

You CAN hook up up to 2 ESDI drives to a WD7000 controller.  There are only
three (?) drives that are supported, though -- the Maxtor 8760E (697MB), the
Maxtor 4380E (329MB FastActuator) and the Micropolis(?) 170MB drive.  The
controller can apparently figure out what's on the other end, and act
appropriately, so there aren't jumpers for the drive type itself.  I think I've
heard that you can add different drive types as your two drives (e.g. a 697MB and
a 329MB drive).

You CAN install up to 2 WD7000 controllers in your system (DN3500/DN4500/DN5500).
The SCSI bus _must_ be disabled on the second controller.

You CAN install a SCSI cartridge drive or floppy, but only if you do not have a
non-SCSI one in place.  If you have a non-SCSI tape/floppy, you must disable the
SCSI bus.

If the SCSI bus is enabled, you CAN add up to 7 SCSI devices total of CD-ROMS,
4mm drives, 8mm drives, and 9-track drives.  I'm not sure whether the 4mm drives
are explicitly supported, but I'm almost certain that I read somewhere that they
work.  I've read that SCSI device 0 is reserved for the cartridge/floppy drive,
but that might have changed.

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

John Thompson
Design Services Engineer / Sys-Admin
Honeywell, SSEC
Plymouth, MN  55441
[e-mail]

[ Also see the separate file "disk-info" .  -- Jim Rees ]


===============

 37)  I'm trying to get a SCSI-2 type disk to work with my Apollo but it
      does seem to work. What did I do wrong?

Answer:

NOTHING. But Apollo doesn't like to be hooked up to an 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 :-)
>
> --
> -----
> +-+  Michael Lampi       [e-mail]
> |R|  R Squared           16398 NE 85th St., Suite 101, Redmond, WA 98052
> +-+                      [phone]       fax [phone]

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.

== Dave Krowitz

===============

 38)  What are the connections in a 3-way serial porst splitter.

I am trying to get a hold of the 3-way serial port splitter for a Apollo
3550 unit.  Would anyone have descriptions on building a cable for this.  At
this time work is unable to justify paying CDN$407 for such a cable.

 -- [e-mail] (Clint Wong)

Answer:

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

Where every first column is the connection to the divided stream.  The
second column indicates the connection made in the joined connector which
goes in the apollo's back.

 -- [e-mail] (Willem Jan Withagen)


===============

 39)  Why do I get:
         Unable to go into maintenance state  User not authorized to
         perform operation (network computing system/Registry Server)

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?

 -- [e-mail] (Robin Brown)

Answer:

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

 [e-mail] (Joe Pato)


===============

 40)  Fixing your 19" monochrome monitor.

My 19 inch monochrome monitor has failed.  Video is fine, but horizontal
sync won't lock up.  How can I fix it for only $1 and half an hour of my
time?

Answer:

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.

 -- Ricky Houghton <[e-mail]>


===============

 41)  How well does SLIP work?

Answer:

Gosh, I guess this needs to be added to the FAQ file, since I thought
I had seen it addressed before.

In any case, 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.)

 -- Nat Mishkin
    Cooperative Object Computing Division / East
    Hewlett-Packard Company
    [e-mail]

Some additional info:  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).  - Jim Rees


===============

 42)  What are the internal names for the various node types?

Answer:

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)

 -- Nat Mishkin
    Cooperative Object Computing Division / East
    Hewlett-Packard Company
    [e-mail]


===============

 43)  Where else can I go besides HP for repairs?

Answer:

I can recommend AMC Computer Services, Inc., 146-B Rangeway Rd.,
N. Billerica, MA., 01862.  Phone: [phone].  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.

 -- HONEYWELL Third Party Computer Service  --  1(800) 525-7439
    Mike Thomas, Senior Technician, Albuquerque, New Mexico
    [e-mail]   [phone]


===============

 44) How do I find out about, and fix, bad spots on my disk?

Answer:

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

From: [e-mail] (Paul Szabo)
Newsgroups: comp.sys.apollo
Subject: Bad blocks on disk (was: Re: SCSI disks on a HP 9000/400t)
Date: Mon, 4 Nov 91 18:34:24 EST
Organization: Mathematics, University of Sydney

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.

 -- Paul Szabo       [e-mail]


===============

 45)  Why does my dn10000 ethernet interface stop working?

Answer:

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

-- Mike Peterson <[e-mail]>

===============

 46)  Has anyone else experienced power-supply problems with their
      Apollo 10000.

>Has anyone else experienced power-supply problems with their
>Apollo 10000 purchased in 1988?  Specifically, I believe the
>problem has something to do with the +5V regulator in the
>power supply.

Answer:

We had to have it replaced.  It would just randomly cause the node to
crash.  The local FE told me it was a well known problem, I think with a
bad lot of capacitors that will fail early.

Mike

  Michael Zeleznik              Computer Science Dept.
                                University of Utah
  [e-mail]          Salt Lake City, UT  84112
                                [phone]
And:

We've had two distinct types of crashes on our 1988 10K.  The first was
definately a power supply problem - The system would randomly shut itself
down completely ie: all lights out.  Inspection of the tell tail leds
inside the box indicated that the 5v rail was low.  We've had the power
bricks replaced (twice!) and it seems to have fixed the problem.  The
other is also random but differs in that the shutdown is not complete.
The response center do not believe it is related but I'm not so sure.
The system is left at the IP0> prompt and we get error messages like:

Stop CPUs with NMI...
fault on CPU 0 (sometimes 1,2 or 3) pc= ...etc
bus/mmu execute trap: page fault fpc=frozen fa=frozen mmu_csr=0000008A

And:

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

                             -jjw
[e-mail]

 47)  Former maintainer:
>  I am no longer able to maintain this file, so its contents
>  may be somewhat out of date.  The latest version of this file, and the
>  auxiliary documents referred to here, are available by AFS in
>  /afs/umich.edu/group/itd/archive/apollo or by anonymous ftp at
>  archive.umich.edu ("cd apollo").

>  -- Jim Rees, University of Michigan IFS Project, March 1992

 48)  Contributers.

      Well there are a lot more people who give sensible answers, so
      If you feel left out. Please let me know. (WjW)
      (And they are in the order in which they appeared in the original FAQ)

      Jim Rees              [e-mail]
      John Thompson (jt)    [e-mail]
      Greg Rocco            [e-mail]
      Jim Richardson        [e-mail]
      Ian Hoyle             [e-mail]
      Paul Killey           [e-mail]
      Bruce Orchard         [e-mail]
      Annegret Liebers      [e-mail]
      Willem Jan Withagen   [e-mail]
      Fred Stluka           [e-mail]
      Carlton B. Hommel     [e-mail]
      John A. Breen
      Walt Weber            [e-mail]
      Leonard N. Zubkoff
      Michael K. Gschwind   [e-mail]
      Harald Hanche-Olsen   [e-mail]
      Bryan Province        [e-mail]
      Carl Heinzl           [e-mail]
      Jinfu Chen            [e-mail]
      David Todd            [e-mail]
      David Krowitz         [e-mail]
      Paul Szabo            [e-mail]
      Frank Teusink         [e-mail]
      [e-mail]
      Eric Bratton          [e-mail]
      John Vasta            [e-mail]
      Dave Clemans          [e-mail]
      Peter Kutschera
      Michael Lampi         [e-mail]
      Clint Wong            [e-mail]
      Robin Brown           [e-mail]
      Joe Pato              [e-mail]
      Ricky Houghton        [e-mail]
      Nat Mishkin           [e-mail]
      Mike Thomas           [e-mail]
      Mike Peterson         [e-mail]
      Michael Zeleznik      [e-mail]
      Jim Waldram           [e-mail]
Digital Information Systems Group, Room EH 10.35
Eindhoven University of Technology
P.O. 513                             Tel: [phone],Fax: [phone]
5600 MB Eindhoven                    The Netherlands