Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/answers/apollo-faq/part2

Internet Message Format | 1993-12-02 | 82KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nic.hookup.net!decwrl!ames!agate!howland.reston.ans.net!EU.net!sun4nl!tuegate.tue.nl!news.win.tue.nl!eba.eb.ele.tue.nl!eba.eb.ele.tue.nl!not-for-mail
From: [e-mail] (Willem Jan Withagen)
Newsgroups: comp.sys.apollo,news.answers,comp.answers
Subject: comp.sys.apollo monthly FAQ (part2/2)
Supersedes: <apollo-faq/[e-mail]>
Followup-To: comp.sys.apollo
Date: 1 Dec 1993 01:00:31 +0100
Organization: Digital Systems Group, Eindhoven University of Technology, The Netherlands
Lines: 1950
Sender: [e-mail]
Approved: [e-mail]
Distribution: world
Expires: 12 Jan 1994 00:00:12 GMT
Message-ID: <apollo-faq/[e-mail]>
References: <apollo-faq/[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: ebs.eb.ele.tue.nl
Summary: This posting contains frequently asked questions for
    HP/Apollo systems running the Domain/OS.
Keywords: FAQ, Apollo, Domain/OS
Xref: senator-bedfellow.mit.edu comp.sys.apollo:17141 news.answers:15223 comp.answers:2856


Archive-name: apollo-faq/part2
Archive-location: ftp.eb.ele.tue.nl:/pub/apollo/FAQ


 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?
        Or what should I know about Apollo/NFS

 (WjW's note:
   I intend to keep some 'trivia' about NFS in this entry.
   Probably until it grows out of bounds, and then make it into
   a really compilled list. So keep the remarks coming.
 )

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

For performance reasons, mounting // is not recommended.  I did this
with Domain NFS 2.3 and an HP 710 (running HP-UX 8.07) and it was
horrible.  The recommended action is that you run NFS 2.3 (or 4.1 when
it becomes available) on all nodes and mount them independently as if
they were ordinary Unix machines with NFS out there on the net.

I have not had a chance to do this since my 700 went bye-bye and I have
no need to do this with my other HP-UX machines (running totally
unrelated applications and data.)
--
Chuck Tomasi             |   "A munk a clone and a Ferengi
[e-mail]    |    decide to go bowling together..."
spool!cserver!edsi!chuck |             -Data "The Outrageous Okana"

-- AND ---------
[3-jun-93]
> Scott Cokely ([e-mail]) wrote:
> : ...
> : doing this is to pick a single Apollo that will export //, making
> : the whole network available to the UNIX side.  Then your automount maps
> : contain entries that point to any directories you want on the Apollo
> : ...
>
> NO!  Do not do this!  Please read the previous followup message I
> posted.  It explicitly states not to export //.  This could actually
> give you VERY poor NFS performance.  This scenario requires  the node
> exporting //  to handle ALL nfs traffic, and all your 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.
> The also create a huge network bottleneck.

Agreed.  Originally, mounting // looked like a good idea to us.  It is certainly
the EASY solution, since any Apollo can export the whole file system, and you
then don't need to worry about lotsa static mounts, or setting up the automounter,
or setting up export lists everywhere, or ....
HOWEVER...  IT IS A HUGE TIME-WASTER.  THE PERFORMANCE SUCKS COMPARED TO HAVING
EACH SYSTEM MOUNT THERE OWN '/' DIRECTORY.

> : ...
>     one way to do this is to merely run the automounter on the
>     HP-UX box.
>
>         /usr/etc/automount /net -hosts

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.


-- jt --
John Thompson
Senior Design Automation Engineer / Sys-Admin On The Loose
Honeywell, SSEC
Plymouth, MN  55441
[e-mail]

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

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

-- jt --
John Thompson
Senior Design Automation Engineer / Sys-Admin On The Loose
Honeywell, SSEC
Plymouth, MN  55441
[e-mail]
===============

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

Answer:
15-okt-93]

In order to prevent the changes being rejected by Cygnus support,
I had to make major modifications to my patches. The modifications
were made to a unreleased versions of gas and gdb, and consequently
are of little use until the next released versions.

The changes to gas were incorperated into the Cygnus support code
early this week. I will check the results over the weekend. If all
goes smoothly, the next release of gas (probably gas-2.2) should
work for Apollos as delivered, but will require gcc to compile.

Additioinally, I had to remove the SysV configs because they were
out of date and unworkable. They will need to be redone, but it
should be a simple modification of the BSD ones.

gcc-2.5 is coming out shortly. This means that the Apollo modifications
won't make it into the released version of gcc until 2.6. However,
once gas 2.2 comes out, I will post the patches required to make
gcc 2.5 write Apollo debugging information.

I haven't heard back from the gdb people, but that could just mean
that the changes were added in with no hiccups. I'll check that
over the weekend too.

> Also related questions:
>
>  1. The README.APOLLO file found in gcc-2.4.5 is for gcc-2.0. Is it
>     still applicable?

It is mostly applicable. See the comp.sys.apollo FAQ for an update.

>  2. Has the gas patch been added to gas' source code and config
>     script yet? Does one still need to apply the patch when installing
>     gas (or gcc)?

See above. Release 2.2 will have it. It will also be capable of guessing
the Apollo configuration, but no guarantees for anything other than
m68k-apollo-bsd4.3 compiling out of the box.

_______________________________________________________________________________
[e-mail]          Overworked, overcommited and always multitasking.
Opinions expressed are not those of the CBME or UNSW, but are my opinions only.

[ The following is more with regards for the older GCC (aka 1.xx)
  I'll leave it in for a while. wjw
 ]

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', 'T' or 'S' type 400 series.

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 :-)
>
[And added on 2-9-93]
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.

(Yes, I submitted this program at the last IWorks Conference, and use it
all the time in my job.)
--
Michael Lampi         [e-mail]
MDL Corporation       15301 NE 90th Street, Redmond, WA 98052
                      [phone]    [phone] FAX

---------------

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?

    Willem Jan Withagen

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

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

 37a) Get a new PROM from HP and it does run SCSI-2 on 425t's
[2-9-93]

=>I recently received some 425ts with SCSI-2 drives.  Specifically, they
=>contained dual 210Mb Quantum PD210S.  After what seemed to be a successful
=>invol and install, the disks were no longer readable. I was using Domain/OS
=>10.3.5.
=>
=>However, with the installation of new boot proms by HP, the disks now work fine.

Dick Harrigill, an independent voice from:     Boeing Commercial Airplanes
M/S 9R-49  PO BOX 3707                       Renton Avionics/Flight Systems
Seattle, WA  91824                                  Computing Support
[phone]    [e-mail]    CDP, PP-ASEL

HP/Apollo 4xx series machines will use SCSI-2 disks PROVIDED that the proper
MD PROM is installed in the system.

 -----------
For example, on my system:

$ scsi_info
[deleted empty devices]
Target 5:
Device Type: Disk
Vendor: QUANTUM
Product: PD210S
Rev Level: 508D
ANSI version compliance: SCSI-2
Features supported: Synchronous Data Xfer; Linked Commands;

Target 6:
Device Type: Disk
Vendor: QUANTUM
Product: PD210S
Rev Level: 508D
ANSI version compliance: SCSI-2
Features supported: Synchronous Data Xfer; Linked Commands;

 -------

In order for us to use these disks in a 425t, HP needed to come out and
swap Boot PROMS.  The MD says our version is:

 MD11 REV 3.21  1992/02/20.15:57:25
 BOOTROM Rev. 3.11  19 NOV 91

--
Dick Harrigill, who cannot speak for:         Boeing Commercial Airplanes
M/S 6X-ME  PO BOX 3707                      Renton Avionics/Flight Systems
Seattle, WA  91824                                 Computing Support
[phone]    [e-mail]       CDP, PP-ASEL

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

 37b) Connecting Old ESDI drives to a SCSI interface?
[2-9-93]

[e-mail] (Willem Jan Withagen) writes:
>    It seems that Adaptec makes a translator which allows you
>    to connect ESDI drives to SCSI controlers.

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

 - dave
--
------------------------------------------------------------------------------
| David Lacey, M.D.                  |"But soon, soon, soon... the world will|
| Resident, Radiology, Univ of Iowa  |be a better place, with meadows and    |
| President, Iowa Student Comptr Assn|bunnies and fiber optics in every home"|
| [e-mail] (NeXTmail OK)|       - Tom Dowdy, Apple Computer     |
------------------------------------------------------------------------------

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

 37c) Using old ESI drives in PC's?
[30-11-93]

In article [e-mail], [e-mail] (Steve Levesque) writes:
>I took a Maxtor 4380E disk drive out of one of our Apollo nodes, and am trying to
>get it to work on a PC. However, I'm not having much succes.
>
>It's a 386 running DOS 5, and an NCL 5355 disk controller. When I run debug and
>low level format it, all seems well. It says the proper number of cyl, heads
>and sectors, but when I run fdisk and format, it thinks its only a 52 MB drive.
>
>I was able to get it to about 150 MB by playing with the CMOS settings, but no
>higher. Using Norton Utilities, I modified the boot table to a higher
>number of cylinders, and then fdisk saw 270 MB, but after formatting it, it was
>unreadable by DOS.
>
>Does anybody out there now how to get one of these disks too work on a PC?
>
>Any help would be appreciated.
>
>Stev Levesque


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

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

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

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

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Tom Wowianko             | [e-mail]  313-998-2408 |
| Allen-Bradley Co.        | A Rockwell International Company |
| 555 Briarwood Circle     | Ann Arbor, MI 48108  USA         |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===============

 38)  What are the connections in a 3-way serial port 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]

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

 48) TCP/IP problem with routing

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

  Keith Marlow ([e-mail])

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

 48)  Can I add serial ports to DN{345}x00 nodes

> I was wondering if anybody out there has had any experience with installing an
> internal modem on a DN3X00.
> What do i need to do in order for it to work.
> Do i need a device driver.  If so does anybody have one written..

I've got a DN3000 on my desk and for a while it had a STANDARD
IBM-PC internal modem.  We used it for UUCP access to the
InterWorks node.  Our parent company got connected to UUNET and
so I hadn't used the modem in a long time.  When I tried to use
it again I didn't have immediate success, but I didn't try very
hard to make it work either.  Here is what I remember doing:

1. Yes, you need a device driver.
2. Apollo already has one.  It's called SPE and it supports 2
   serial ports and 1 parallel port.
3. If you configure the modem at address 3f8 and interrupt 4
   then you can use the 'spe_tty_sio1_ddf' to access the modem.
4. The SPE installation will create TWO serial device
   descriptions in /dev/global_devices.  You need to DELETE the
   one for spe sio2 since this device does not exist on your
   "SPE" card.  If you don't you will get an error message when
   you boot your machine.  It will be unable to initialize the
   second serial device.  If you don't delete it before you shut
   down the node, you will need to delete it from the phase II
   shell.

[AND]

I posted earlier how to added an internal modem card to an AT bus
DN series node.  I also stated that it wasn't working anymore.

Well...  I found the problem.  This particular card has the
configuration switch (COM1/COM2) is on the OUTSIDE.  Where it
could easily (and was) bumped and changed.  Once it was moved to
the correct position, everything worked like it always did.

There is now a V2.2 of SPE (which is REQUIRED for SR10.4 but
also runs on 10.1-10.3)

Lastly, be aware that Apollo warns of input overrun errors
when using the SPE ports at speeds above 4800 baud.  There is
insufficient buffering on the card to support these higher speeds
and you may loose data if the node is loaded.  Faster nodes
should have fewer problems, but your milage will vary.  Consult
the release notes that come with the SPE software.

Philip D. Pokorny
[e-mail]

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

 49) What is needed to run the Post-office deamon.

: =>
: =>   Has anyone sucessfully compiled a POPmail server on
: =>an Apollo 425t running Domain OS 10.3.5.3 ? I would very
: =>much like to get a POPmail server running on our Apollos
: =>and would like any information from anyone that has succeeded
: =>at doing this.    Thanks in advance...
:
: I got ours just from either the NET or from the SUN lifeline mail package.
: I can't remember having to tweek it hard. (at least no notes of that).
: The only thing is that it runs wild now and then, it swamps the node with
: popd's ( >100), and the node has to be shut.
: Also is there a protocal violation on something, since the popd image goes
: to the ZOMBIE state and stays there until a new popd request comes in.
:
: We're running 10.3.5 and 10.3.5.7 Full BSD.
: You can get our executable:
:  ftp.eb.ele.tue.nl:/pub/apollo/local/etc/popd
:

I think that's version 2 of the protocol.  You might want to try version 3:

        ee.utah.edu:/pop3/popper-1.831beta.tar.Z

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

Bill Neisius
[e-mail]

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

 50)  MIT X11 R5 Core & GUI Classic Distribution

Due to popular demand, HP has made available via its InterWorks users group
the following distributions:

  o source and binaries for the entire generic MIT X11 R5 Core Distribution
    (including a sample server)
  o source for outdated or sample X user interface products

Ken Steege
[e-mail]

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

 51)  Funny Status codes and their backgrounds.
 (By many sources)

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

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

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

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

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

 52)  What is the use of an ATR card in a HP9000/7xx?

In article <[e-mail]>, [e-mail] (Peter E. Giza) writes:
|> Herb Peyerl Writes:
|> |>If you want to make the assumption that IP packets are encapsulated within
|> |>DDS packets, then in order to make HP-UX reside on ATR, HP must then have
|> |>ported DDS to HP-UX on 400's and 700's... That must mean 700's have
|> |>node-ids. Somehow I doubt that.
|>
|>
|> Just for the record.  The ATR cards are same with the exception of
|> few changes for the HP.  The packets are encapsulated in a 73 byte
|> DDS header just like good ole Domain, this is all done at the driver
|> level for the card.  All of the DDS-like behaviour is from the driver
|> there is not a complete DDS port, just enough to make you pregnant.
|>
|> -peg
|>
|> Peter E. Giza HP DCE T&D ~:@)

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

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

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

    1) lcnode

       long list returned including some uncataloged nodes

    2) bdlt -n NNNNN

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

    3) ctnode foobar NNNNN -root

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

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

Well, this got kinda long, but I've been watching this argument fester on
the net for a while and I just couldn't stay out of it any longer (fools
rush in...). I hope that my explanation helps clear up any questions that
may have been lingering. Even if you don't agree with my implementation
choices, at least now you have some idea why I did it the way I did.

BTW: I'm not the person who maintains this driver nowadays. That's done
     in another division by someone who still does lan drivers for a
     living, so yelling at me to "FIX IT" won't have much effect. It's
     not that I'm not sympathetic, but I don't even have access to the
     code anymore.

Best regards to all of you who still love Domain. With any luck we'll have
something as good again someday.

--
Carl Davidson  [phone]  |
Chelmsford System Software Lab | Microkernels: Where less is more.
The Hewlett-Packard Company    |
DOMAIN: [e-mail]      |

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

 53)  How do I get my Emacs keydefinitions back when running under X?

We have been using Leonard N Zubkoff's ([e-mail]) 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 attached 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!

----------------------------------------------------------------------------
Kevin Gallagher        [e-mail] OR ...!uunet!digi!kgallagh
DSC Communications Corporation   Addr: MS 152, 1000 Coit Rd, Plano, TX 75075
----------------------------------------------------------------------------

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

===============
 54)  What do I need to emulate a PC on apollo?
    or DPCC, DPCE, and DPCI support

Since the PC connectivity and AT-coprocessor have been mentioned
here several times recently, I thought I'd share some commercial
availability information.  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. [phone]
FAX  [phone]
Net  umech![e-mail]


Disclaimer: I am in no way connected with the above vendor.

-----------------------------------------------------------------
 Rick Venable                  |    "Eschew
 FDA/CBER Biophysics Lab       |   Obfuscation"
 [e-mail]        |         -- the Phantom Nerd
-----------------------------------------------------------------

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

 55)  I am looking for a font to use under X that will match the DM font
    f7x13.b.  I like the size and shape of the characters and would like
    as close a match as possible.

  Any suggestions?

Why not just use the f7x13.b font?

I thought I had put this in the FAQ, but I don't see it there now.

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?

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

 56)  How does one manage a NIS database and the Domain registry?

From: [e-mail] (System Admin (Mike Peterson))

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

Maintainers note:

I've saved the first version available for anon-ftp:
    ftp.eb.ele.tue.nl:/pub/apollo/scripts/NIS+registry
But be shure to contact Mike for an update.

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

 57)  Can I convert my apollo into an X-terminal?

This question is answered in a seperate file (~190 lines).
By Dusan U Baljevic
The file can be found at:
    ftp.eb.ele.tue.nl:/pub/apollo/notes/make_an_X-terminal

===============
 58)  What can I do with old parts from DN3100's, and probably other DN????'s

 58a) Is there any way to use the controller+monitor on a Windows PC

Russell Crook ([e-mail]) asks:
: (1) Is there any way to use the controller+monitor on a Windows PC
:     (that is, is there a Windows driver for this proprietary controller?

And [e-mail] answers:

There isn't currently one... One could be written but there are some
problems... I started writing a Unix driver for the cards but gave up
due to the futility of it.. There are Super-VGA cards on the market
that are fairly cheap that will outperform anything you could do with
the Apollo cards... The other problem is that the adapters are entirely
bitmapped which means there is no character capability there whatsoever
and they don't conform to any sort of "PC" standard which you may be
used to (thank god for that!)... The live in a large amount of shared
memory which makes them unusable as a second display since they live in
the same place where your other display adapters would live... The 8 plane
cards can be jumpered to live elsewhere but unfortunately that's right
about where your BIOS lives..

The other problem is that the cards were developed for the Apollo's and
even though they plug into an ISA bus; that's about where the advantage
stops.. The Intel platform is byte-backwards relative to the Motorola
that the Apollo's have in them... Consequently; most operations that you
perform on the card will have to be byteswapped which eats up extra
cycles...

I got about as far as uploading the character set from BIOS into the
zbuffer of the card; then blitting characters from there onto the display
and scrolling the display up when the text got to the bottom... Basically;
I could "type file | driver" and see it... It was pretty slow relative to
a card that has character capabilities (of course)... Next step would have
been a Unix Console driver but I sort of stopped there.. A few people have
asked me for the code since then but I've never heard anything else from
them so I imagine they gave up too... It's not that it's difficult; just
that the end product probably won't be that great...

Oh; the other thing is that the cards don't respond to bios' queries
during boot so boot fails... You always end up booting blindly too
unless someone were to rewrite a bios that recognized this card.. While
they're at it; write a bios that recognizes SCSI and...and...and...

: (2) Failing this, does the monitor itself accept one of the many standard :->
:     PC display signal levels, and is there a card that will drive the
:     monitor at 1280x1024?

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

[NOTE: by Herb Peyerl
 I've tried the same circuit with the hi-res monitors (1280x1024) and
 it works even better on those! ]

[NOTE: by WjW. The diagram is also in the file
 ftp.eb.ele.tue.nl:/pub/apollo/notes/monitor-sync.ps
]

the Xfig diagram for the simple little circuit is available from the
author of the diagram ([e-mail]) or myself... I haven't
asked Tony if he'd mind distributing it so be nice to him.

: (3) Failing (1) and (2), is there any other use for these machines, since
:     I do not have documentation or a diskfull Domain server to run them?

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

"I was early to finish | [e-mail] <Reply-To>   | I brew |
I was late to start, I | [e-mail]                     | there- |
might be an adult, but | #define JANITOR "Network Anal-yst"     | fore I |
I'm a minor at heart." |    JANITOR, NovAtel Communications Ltd.|   AM.  |

-- AND -------
 58b)  What can I do with an old SMS-OMTI harddisk controller
[3-jun-93]
In article [e-mail] (Andrew F Gunnesch) writes:
|> Hi there.  Someone out there must know how to jumper an
|> Apollo disk controller for use in a PC.  I've tried several
|> different ones, including the SMS controllers and even a
|> WD7000V-ASE with no luck.  The floppy side seems to work
|> just fine...  I even think that on one controller I got
|> the IO address space correct, but probably messed up on the
|> DMA channels.  I don't know...  if anybody out there can
|> help me (Hey old Apollo employees, you listening?)  Ideally,
|> of course, I'd like to be able to use the WD7000, but if
|> somebody can help me out using ANY of those controllers I'd
|> really appreciate it.
|>

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

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

--
steve swamp                       BNR
email: [e-mail]               Research Triangle Park, NC
================

 59) How to prevent a system-hang when booting while preserving editor files.

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

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

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

 60) What (display) mgrs are needed for what type of system

[3-jun-93]
In article [e-mail] (jt -- John Thompson) writes:

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

As was previously mentioned llkob will tell you which managers are in use
on a specific system. Beyond that display type managers at the
/sys/mgrs level are used by G*R, while the type managers in /sy/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 :  color12
dtm_tsg2d      PVRX on Series 400 color13
dtm_wood       433e built in graphics controller15
dtm_color14    CRX 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 color4
dtm_dn10000_8  8 plane 1280x1024 on dn series color5
dtm_mk3        8 plane 1280x1024 on dn series color6

 Rob Raymond                       Internet: [e-mail]
 HP/Apollo 6U-298
 3404 E. Harmony Road              Fax:      [phone]
 Fort Collins, CO 80525-9599       Phone:    [phone]

 60a) Specifications of monitors once sold by HP/Apollo
    [30-jun-93]
From: [e-mail] (Russell Ayling)
To: [e-mail]
Subject: Apollo FAQ - monitors info.
Status: OR

I compiled this info a while ago from an HP source plus bits
and pieces I picked up.  There are frequent questions about the
monitors (esp. frequency) so maybe this, or part of it, could go
in the FAQ.  (I've mailed this out many times already, it would
be easier to just refer people to the FAQ.)

[ The file is rather long so it's available from:
    ftp.eb.ele.tue.nl:/pub/apollo/notes/monitor.info

    WjW
]

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

 61) Installing an Ethernet Controller in an Apollo DN4000

[ The full story is available as:
    ftp.eb.ele.tue.nl:/pub/apollo/notes/ehternet.info

    WjW
]

In article <1vk1qm$[e-mail]> stevie@payot (Stefan Wende) writes:
>I have a problem trying to make TCP/Ip work on a DN 3000 (yes, I know, its
>old stuff, but its all I got).
>Any pointers would be greatly appreciated.
>

This might help:
-------------------------


Installing an Ethernet Controller in an Apollo DN4000
            and
        Living to Tell About It


April 20, 1992

Mark C. DiVecchio
Silogic Systems
9888 Carroll Center Road Suite 113
San Diego, CA 92126

email           ...!ucsd!celit!silogic!markd
                [e-mail]

Table of Contents


1.0 Environment. . . . . . . .  4

2.0 3C505. .  4

3.0 Run the Jumper Program . .  4

4.0 Test tcp/ip. . . . . . . .  6

5.0 Shut Down the Node . . . .  6

6.0 Installation of the Ethernet Card. . . . . .  6

7.0 Test the Ethernet Card . .  6

8.0 Boot the Node. . . . . . .  6

9.0 Edit These Files . . . . .  7
        9.1 /etc/hosts . . . .  7
        9.2 /etc/hosts.equiv .  7
        9.3 /etc/networks. . .  8
        9.4 /etc/rc. . . . . .  8
        9.5 /etc/rc.local. . .  9

10.0 Check Files . . . . . .   10
        10.1 /etc/inetd.config . . . . . . . .   10

11.0 Edit /etc/daemons . . .   11

12.0 Reboot the Node . . . .   11

13.0 Check It Out. . . . . .   11

14.0 Edit /etc/hosts files .   12

15.0 Test tcp/ip . . . . . .   13

16.0 tcpst Utility . . . . .   14
        16.1 tcpst Options .   14
        16.2 tcpst Listing .   14

17.0 Acknowledgements. . . .   17

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

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

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

999)  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]
      Keith Marlow          [e-mail]
      Philip D. Pokorny     [e-mail]
      Bill Neisius          [e-mail]
      Ken Steege            [e-mail]
      Robert Stanzel        [e-mail]
      Carl Davidson         [e-mail]
      Dick Harrigill        [e-mail]
      Michael Pins          [e-mail]
      Todd Allan Postma     [e-mail]
      Dusan U Baljevic      [e-mail]
      Herb Peyerl        [e-mail]
      Rob Raymond           [e-mail]
      Russell Ayling        [e-mail]
      Mark C. DiVecchio     ...!ucsd!celit!silogic!markd
                            [e-mail]
      Donnie Collins        [e-mail]
      David-Lacey           [e-mail]
      Troy Rollo            [e-mail]
      Tom Wowianko          [e-mail]

--
Digital Information Systems Group,     Tel: [phone], Fax: [phone]
Room EH 10.35  Eindhoven University of Technology
P.O. 513, 5600 MB Eindhoven, The Netherlands                          TEAM OS/2
Internet:[e-mail], X400:C=nl;A=400net;P=surf;O=tue;OU=ele;OU=eb;S=WJW;
--
Digital Information Systems Group,     Tel: [phone], Fax: [phone]
Room EH 10.35  Eindhoven University of Technology
P.O. 513, 5600 MB Eindhoven, The Netherlands                          TEAM OS/2
Internet:[e-mail], X400:C=nl;A=400net;P=surf;O=tue;OU=ele;OU=eb;S=WJW;