Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!pisa.citi.umich.edu!rees
From: rees@pisa.citi.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo Miscellany
Keywords: Apollo, Questions
Message-ID: <51ff0905.1bc5b@pisa.citi.umich.edu>
Date: 5 Jun 91 21:31:24 GMT
References: <912@bcstec.boeing.com>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 54

In article <912@bcstec.boeing.com>, ruben@bcstec.boeing.com (Reuben Wachtfogel) writes:

  Apollo Miscellany

Glad to see the folks at the Lazy-B Ranch (one of my many ex-employers, and
the place where I first encountered Unix, in 1977) still have a sense of
humor.

  3)  Why do my black and white dn3000s feel faster than my 
      F-series 4500s...

Why does my dn330 feel faster than my dn3500?  Maybe it's because I run
sr9.7 on my dn330.

  6)  This little man showed up at work and told me that we don't like  
      Apollo's Token ring anymore and that ethernet is gobs better.
      He had such a pleasant smile but gosh I just don't know. Does
      anybody out there have a probelm with this ?

I sure do.  NACKs are so much nicer than timeouts when nodes or routers go
bad.  Besides which, it's (in general) impossible to boot diskless on an
ethernet, unless the ethernet is only used by Apollo nodes, and even then
it's a problem.  The bug is that netboot seems to be unable to discard
packets intended for that node but not of the proper type (say, xntp peer
packets when it's expecting bits of Domain/OS).  There are other theoretical
differences, but these are the ones I notice every day.

  B)  How cum some people seem to know how to use unsupported and 
      undocumented apollo commands ?  Did they use to work for Apollo ?
      Do they reverse engineer the stuff or use the debugger ? Are they
      just good guessers ? Anybody care to share a method,list,or insight ?

I've been meaning to write up something about this.  I used to work for
Apollo, and I have access to source code.  But if I had none of these
advantages, I would proceed as follows:

1.  Write a program (call it "syscall") that takes the name of a system
call, looks up its entry address in the KGT (using kg_$lookup), then
interactively reads a list of arguments, makes the call, and prints out any
args that have changed.

2.  Run "nm" on the contents of /com and /systest/ssr_util to find
interesting system calls.  Run "nm" on /lib/pmlib for a list of all system
calls (and lots of good library calls, too).

3.  Run "syscall" on the calls revealed in 2.  Experiment.  Crash your node.
Have fun.  Learn something.

  C)  Ever notice how all the usefull facilities end up in 
      /systest/ssr_util ? Whom do I have to kill to get the source code
      to those things ?

Bring me the broomstick of the Wicked Witch of the West...  I don't think
you get this even with a source license.