HDTenEightyP/NetNews huggingface dataset:
From: mitchell@aaec1.aaec.com
Newsgroups: comp.os.vxworks
Subject: re: Intertask communication mechanisms
Date: Thu, 1 Oct 92 09:42:00 EDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

# 
#   SMB> 1.  TCP throughput is too low.
#   SMB> 2.  UDP throughput is too low and potentially too unreliable or
unordered.
#   SMB> 3.  I have to write my own mechanism.
#   SMB> 4.  There is something better out there that I'm not aware of.
# 
# Why not simply use shared memory (assuming your VME board supports it)
# and use TCP sockets to tell that data is available to the other board.

Sadly, I never received the original mail message that started all this
traffic,
but from what I gather, this is about inter-processor communications more
than
inter-task.

We developed a "Global" semaphore library for a multi-CPU chassis for
vxWorks 4.
It was based on mailbox interrupts, RINGs, and statically semaphores (the
old
type).  For N processors, there was N by N array of RINGs, and each "Gsem"
had N local (vxWorks) semaphores and pending counts, and a flag to vxTas().
 With the NxN RING array was a array of data for the processor mailbox
address and size (byte, word, longword), allowing different CPU types to be
used.  The Gems provided a simple binary semaphore mechanism for
inter-processor control.  Shared memory was used to pass data back and
forth using switched buffers.

"GsemTake" would try to take the gloabal flag with a TAS, if it failed, it
would increment its processor's pend count and take the local semaphore. 
"GsemGive" is passed a pointer to the "Gsem", and a bit mask of all the
processors to hit.  It would put the address of the Gsem in the correct
"from-CPU--to-CPU" mailbox, clear the TAS flag, and hit the proper
mailboxes.  

The mailbox interrupts would check all their "to-CPU" RINGs and semGive the
local semaphore if the pending count was non-zero.  All the target CPUs
fought for the semaphore, the winner depending on bus priority and possibly
order in which they were hit.  There ended up being only one target CPU in
each call, so this was quite an overkill in the end.  

For inter-chassis communications, we used our version of Ultra-Net.  It
moves data between chassis at up to 12 MBytes/second using stream sockets. 
The CPU overhead is about 1mS per socket call, so big moves (read/write
calls with >1 Meg buffers) keeps CPU utilization below 10%.  The Adapter
has an on board 386 and ECL checksum logic to handle that protocol junk. 
Once a socket was set up, the event of a return from the read call was used
to loosly syncronize events in the other chassis.

Implementing both of these was painfull.
  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200 
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
From: flash@austin.lockheed.com (James W. Melton)
Newsgroups: comp.os.vxworks
Subject: Interphase 4211 driver revisited
Date: 6 Oct 92 00:45:08 GMT
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744

A little while back, I posted my experience getting the Interphase
4211 FDDI board operational. My comments drew some consternation
from the folks at AP Labs. After talking with them, I offer the
following clarifications:

1) Interphase told me they paid AP Labs to write the driver. AP
   Labs said this is not correct.

2) AP Labs says that while they are (obviously) not obligated to
   help people who have not purchase their product from them, their
   policy is to answer 1 phone call, if you get through to their
   customer support engineer. I did not get through, so this was
   not my experience.

3) AP Labs says that if I *had* reached their customer support
   engineer, he would have been able to tell me in short order that
   I had an old version of the driver, and that my problems had
   been fixed some time ago.

   After this conversation, I called Interphase and asked them what
   version of the driver I should have. Indeed, they had a later
   version, which they are shipping to me.

What I posted earlier is factually correct, and represents my
experience in dealing with AP Labs and Interphase. AP Labs is
concerned that my comments cast aspersions on their products and
service. Never having dealt with AP Labs commercially, I am not
quallified to comment on their products or service.

However, when I configured this system (software only, the hardware
was provided), I asked Wind River if they could get me the FDDI
driver. I had previously confirmed its existence by calling
Interphase. My WRS sales person said we could get it. After calling
for months, the local Interphase distributor showed up at my door
with a tape. This was what I had to work with.

I am not interested in assigning blame to anyone. My concern as a
customer (of SOMEONE) is to get my system working. Other people
will, no doubt, have similar experiences in obtaining device
drivers. When I buy a board from a vendor who claims to have a
vxWorks device driver, it *should* work! I don't buy a separate
device driver support package when I buy a board for my Unix
systems. I shouldn't have to do this for vxWorks.

As always, just my opinions and experience, etc. Your mileage may
vary.

-- 
Jim Melton, novice guru
email:      flash@austin.lockheed.com | "So far as we know, our
voice mail: (512) 386-4486            |  computer has never had
fax:        (512) 386-4223            |  an undetected error"
Newsgroups: comp.os.vxworks
From: Ninane@fynu.ucl.ac.be
Subject: Re: Intertask communication mechanisms
Followup-To: comp.os.vxworks
Originator: nina@fynu4.fynu.ucl.ac.be
Organization: University of Louvain (LLN) - Nuclear Physics Dept.
Date: Fri, 2 Oct 1992 07:10:20 GMT

In article <1992Sep30.052936.15428@afterlife.ncsc.mil> smb@afterlife.ncsc.mil (Steve M. Burinsky) writes:
>I'm exploring my alternatives for intertask communication among tasks on
>the same or other boards.

I have developped, a few months ago, a set of `mininal' multiprocessor
extensions to vxWorks 5.0.  The library includes multiprocessor semaphores
to protect data accross a full VMEbus crate and defines a way to create
multi-processor devices.  This work has been done in the framework of our
local data acquisition system.  At this time, the mp library works with
MVME167 and MVME147 boards; To use it with another SBC, it is needed to
write some mailbox routines which are added to the BSP.  This way, the mp
library works in parallel with the vxWorks IP-on-the-backplane package.

Interested people can get the software by anonymous ftp on
130.104.3.1 (ids1.fynu.ucl.ac.be - sorry we are not yet
registered on name server).  The file is:
		pub/acqFynu-2.0.0.tar.Z

acqFynu contains our data acquisition system.  The mp library is
stored in the `mp' directory of this software.

Because I'm the only person in charge of data acquisition systems in the
laboratory, I cannot promise that I will be able to answer quickly all
questions.
Alain
-- 
Dr. Alain H. Ninane     | Tel : +32-10-47.32.73 - Fax: +32-10-45.21.83
University of Louvain   | Internet: Ninane@fynu.ucl.ac.be
Nuclear Physics Dept.   | Ch. du Cyclotron, 2
B-1348 Louvain-la-Neuve | BELGIUM               
Newsgroups: comp.os.vxworks
From: muts@fys.ruu.nl (Peter Mutsaers)
Subject: Re: Intertask communication mechanisms
Organization: Rijks Universiteit Utrecht
Date: Wed, 30 Sep 1992 08:58:25 GMT

On 30 Sep 92 05:29:36 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said:

  SMB> 1.  TCP throughput is too low.
  SMB> 2.  UDP throughput is too low and potentially too unreliable or unordered.
  SMB> 3.  I have to write my own mechanism.
  SMB> 4.  There is something better out there that I'm not aware of.

Why not simply use shared memory (assuming your VME board supports it)
and use TCP sockets to tell that data is available to the other board.
--
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@fys.ruu.nl         |        Quod licet bovi, non licet Jovi
From: doctor@kronos.arc.nasa.gov (Terry Fong)
Subject: bug with mutex semaphores in 5.0.2???
Summary: is there a bug????
Keywords: semaphore, bug, 5.0.2
Organization: NASA/ARC Information Sciences Division
Date: Tue, 29 Sep 1992 17:51:43 GMT

Hi all,

I seem to be having a problem with mutual exclusion semaphores: they
don't seem to work at all!!!! For example, given the following code:

------------------------------------------------------------------------------
#include "vxWorks.h"
#include "semLib.h"

SEM_ID semId;

waitAndPrint ()
{
  extern SEM_ID semId;

  while (1) {
    semTake (semId, WAIT_FOREVER);
    printf ("got semId!\n");
  }
}
------------------------------------------------------------------------------

I compile under 5.0.2 using cc68k:

  cc68k -O -fstrength-reduce -fcombine-regs -msoft-float -traditional \
	-I/usr1/vw/h -c  waitAndPrint.c

Then in the VxWorks shell:

-> semId = semMCreate (1)		(note: 1 = SEM_Q_PRIORITY)
semId = 0x33fdcec: value = 54264916 = 0x33c0454
-> ld < waitAndPrint.o
value = 0 = 0x0
-> semTake (semId, -1)			(note: -1 = WAIT_FOREVER)
value = 0 = 0x0

By this point, the semId should be empty and anything that attempts to
take it should pend. So, I start up the waitAndPrint task:

-> waitAndPrint
got semId!
got semId!
got semId!
got semId!
.
.
.
(Ctrl-C)

As you can see, waitAndPrint NEVER pends. It ALWAYS is able to take
the semaphore. If I replace "semMCreate (1)" with "semBCreate (1, 1)"
(i.e., use a regular binary semaphore), everything works as expected
(i.e., waitAndPrint pends). So, am I doing something wrong? Or is
there a bug here?

-Terry

-- 
_______________________________________________________________________________
Q:"What do you do with your life?"   | Terry Fong <terry@ptolemy.arc.nasa.gov>
A:"Nothing. But I do it terribly     | NASA Ames, M/S 269-3, Moffett Field, CA
   well!" - John Drake (Secret Agent)| (415) 604-6063 voice, 604-4036 fax
From: rob@cygnus.com (Rob Savoye)
Newsgroups: comp.os.vxworks
Subject: Re: gcc and g++ 2.2.2
Date: 5 Oct 92 19:16:12 GMT
	<pes.718299432@regent.e-technik.tu-muenchen.de>
Organization: Cygnus Support -- +1 415 322 3811
In-reply-to: pes@regent.e-technik.tu-muenchen.dbp.de's message of Mon, 5 Oct 1992 15:37:12 GMT

In article <pes.718299432@regent.e-technik.tu-muenchen.de> pes@regent.e-technik.tu-muenchen.dbp.de (Peter Schauer) writes:

   If you dont use g++ that's ok. But if you use g++ and have destructors that
   need to be called at program exit you have to rebuild libgcc so that it
   happens ok for vxworks.
   And no, I didn't do it, its just a warning.

  Another simple fix is if you don't need C++, then replace the name
of the function main with something else. Since you have to do a spawn
anyway, you can call the main routine anything you want. If there is
no main() in the code, then __main() is never looked for.

	- rob@cygnus.com -
From: Roeber <fjr@ssd.ray.com>
Newsgroups: comp.os.vxworks
Subject: re: Intertask communication mechanisms
Date: Thu, 1 Oct 1992 14:54:45 -0400
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Bob Crispen writes:
>  mitchell@aaec1.aaec.com (Andrew Mitchell) says:
>   
>  >We developed a "Global" semaphore library for a multi-CPU chassis for
>  >vxWorks 4.
>  
>  Are you able to post this or put it in the VxWorks archive?  Or
>  maybe refer to the contract you delivered this on (if it was
>  for one of the Services, and therefore maybe public domain)?
>  
>  We thought about doing the same thing, but I thought you had to do
>  that in the Wind kernel, so I chickened out.  I've got the source,
>  but no guts.

We also implemented a full set of VxWorks multiprocessing primitives
but made certain board architecture assumptions to get optimum performance.
It was a lot of work to get it all running.  At the East Coast VxWorks
user group meeting a few weeks ago though, WRS finally announced that
their multi processor package is almost ready for delivery.
  It looks like it will be pretty good and much faster than
using backplane TCP/IP (which can actually be even slower than ethernet
TCP/IP in some cases due to the fact that the work that an ethernet chip
usually does is now relagated to a CPU).  There wasn't any firm delivery
date that I remember VxWorks quoting but they did say betas for SUN cross
680X0 will go out soon.   Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|
From: interf!zeus!brackett@uunet.uu.net (Todd Brackett)
Newsgroups: comp.os.vxworks
Subject: Driver for GPIB-1014P
Date: Thu, 1 Oct 92 14:13:16 EDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Does anybody have a driver/library for the National Instruments
GPIB-1014P board?  This is the cheap programmed I/O one without 
the DMA.

Thanks,

-------------------------------------------------------
|Todd S. Brackett                 |Voice:703 790 8500 |
|Interferometrics, Inc.           |FAX:  703 848 2492 |
|8150 Leesburg Pike               |                   |
|Vienna, VA 22182                 |                   |
|-----------------------------------------------------|
|Internet:brackett@interf.com                         |
|Uunet:   uunet!interf!brackett                       |
-------------------------------------------------------
Newsgroups: comp.os.vxworks
From: bard@cutter.ssd.loral.com (J H Woodyatt)
Subject: Re: Intertask communication mechanisms
Reply-To: bard@cutter.ssd.loral.com
Organization: Abiogenesis 4 Less
Date: Wed, 30 Sep 1992 17:36:44 GMT

In article <MUTS.92Sep30105823@ruunfs.fys.ruu.nl>, muts@fys.ruu.nl (Peter Mutsaers) writes:
# On 30 Sep 92 05:29:36 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said:
# 
#   SMB> 1.  TCP throughput is too low.
#   SMB> 2.  UDP throughput is too low and potentially too unreliable or unordered.
#   SMB> 3.  I have to write my own mechanism.
#   SMB> 4.  There is something better out there that I'm not aware of.
# 
# Why not simply use shared memory (assuming your VME board supports it)
# and use TCP sockets to tell that data is available to the other board.

IP is probably too slow (TCP doesn't `do' IP broadcast either), so
shared memory is probably the way to go.

You don't have to use TCP on the backplane for interprocess task
synchronization -- use a mailbox interrupt if you have one, or vxTas()
in a polling loop if you don't.

-- 
J H Woodyatt (a.k.a. Dr. Strychnine)
Space Systems/Loral

Help keep Las Vegas clean.  Eat your kill.
Newsgroups: comp.os.vxworks
From: zafer@bcars474.UUCP (Zafer Elbi)
Newsgroups: comp.os.vxworks
Subject: Locking Interrupts..
Keywords: VxWorks
Date: 29 Sep 92 04:17:11 GMT
Organization: Bell-Northern Research, Ottawa, Canada


 

For the following code:

int lock = intLock();
..
..
..--->  Task switch
..
intUnlock();

If there is a task switch occurs in the middle of the interrupt routine, can
the preempting task unlock the interrupts again?

Thanks for the reply..
Newsgroups: comp.os.vxworks
From: pes@regent.e-technik.tu-muenchen.dbp.de (Peter Schauer)
Subject: Re: gcc and g++ 2.2.2
Organization: Technical University of Munich, Germany
Date: Mon, 5 Oct 1992 15:37:12 GMT

rob@cygnus.com (Rob Savoye) writes:

>In article <1992Oct2.084154.2159@aar.alcatel-alsthom.fr> bres@aar.alcatel-alsthom.fr (Guillaume Bres) writes:
>   Indeed some problems arise because gcc refers to ___main
>   which is defined in libgcc.a, and ___main refers to _on_exit
>   which is defined in the sunos libc.a but not in the vx library
>   all.a
>
>What I do is do a partial link using the -r option to gcc. You have to
>build the libraries, but It has other advantages. This bring in the
>__main() function.

If you dont use g++ that's ok. But if you use g++ and have destructors that
need to be called at program exit you have to rebuild libgcc so that it
happens ok for vxworks.
And no, I didn't do it, its just a warning.

Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From: Bob Foery <bobf@verdix.com>
Newsgroups: comp.os.vxworks
Subject: MVME167C boards in backplane network
Date: Mon, 05 Oct 92 17:21:16 +0100
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

I am currently investigating a problem concerning (2) mvme167c boards (32Meg)
booting in a backplane network.

Has anyone successfully booted a slave '167c?  If so, please respond or e-mail
me directly.

Thanks in advance,

Bob Foery
Verdix Corporation
bobf@verdix.com
From: hwajin@mondo.iphasew.com (Hwa-Jin Bae)
Newsgroups: comp.os.vxworks
Subject: Re: bug with mutex semaphores in 5.0.2???
Date: 30 Sep 92 03:22:25 GMT
Organization: Interphase West, Santa Clara, CA
In-reply-to: doctor@kronos.arc.nasa.gov's message of 29 Sep 92 17:51:43 GMT

>>>>> On 29 Sep 92 17:51:43 GMT, doctor@kronos.arc.nasa.gov (Terry Fong) said:
Terry> Nntp-Posting-Host: tardis-arclan.arc.nasa.gov


Terry> SEM_ID semId;
Terry> waitAndPrint ()
Terry> {
Terry>   extern SEM_ID semId;
Terry>   while (1) {
Terry>     semTake (semId, WAIT_FOREVER);
Terry>     printf ("got semId!\n");
Terry>   }
Terry> }

Terry> -> semId = semMCreate (1)		(note: 1 = SEM_Q_PRIORITY)
Terry> semId = 0x33fdcec: value = 54264916 = 0x33c0454
Terry> -> ld < waitAndPrint.o
Terry> value = 0 = 0x0
Terry> -> semTake (semId, -1)			(note: -1 = WAIT_FOREVER)
Terry> value = 0 = 0x0



interesting... it looks like when you compiled the above program, _semId 
gets defined as a common global symbol, not an unknown (external) symbol
(rightly so because you didn't declare it "extern") and
when you create a _semId from the shell it gets entered into
vxWorks symbol table, but subsequently loading the module
overwrites the symbol table entry for _semId.  you may verify
this by printing address of semId from the shell before and after
the loading.  [ i haven't tried this theory so i could be wrong,
but at least that's the way i remember the way vxWorks loader worked ].
the result is that you're not doing the semTake on _semId you
think you're using, and the new one probably contains 0 values
for the counter so semTake just returns, and returns, and....



	~hwajin
From: vreeburg@fys.ruu.nl (Jurriaan Vreeburg)
Newsgroups: comp.os.vxworks
Subject: Re: comp.os.vxworks newsdigest
Date: 29 Sep 92 14:41:21 GMT
Organization: Physics Department, University of Utrecht, The Netherlands

In <9209291230.AA17923@aplexus.jhuapl.edu> prb@aplexus.jhuapl.edu (Paul R. Bade) writes:

>zafer writes:
> 

>-> For the following code:

>-> int lock = intLock();
>-> ..
>-> ..
>-> ..--->  Task switch
>-> ..
>-> intUnlock();

>-> If there is a task switch occurs in the middle of the interrupt routine, can
>-> the preempting task unlock the interrupts again?


>If there are no interrupts allowed, there will be no clock interrupts or 
>other interrupts to bring about a task switch. So the answer is,
>there is no prempting task.

Not completely true. See the man-pages for intLock():


IMPORTANT CAVEAT
intLock() can be called both from interrupt and from task level. When called from a task
context, (which is the case with Zafer), the interrupt lock level is part of the task's context.
Locking out interrupts DOES NOT PREVENT RESCHEDULING. Thus, if a task locks out interrupts and
then invokes kernel services that cause the task to block or causes a higher priortity task to
be ready, then rescheduling will occur and interrupts will be unlocked while other tasks run.
Rescheduling may be expicitly disabled wirh taskLock().

To answer Zafer's question: the preempting task can not intUnlock(), because the lock is not
part of its own context.
 
-- 
Jurriaan Vreeburg                             email: vreeburg@fys.ruu.nl
Department of Physics and Astronomy           tel.:  (+31)-(0)30-534566
P.O. Box 80.000
3508 TA  Utrecht  Holland
From: Laurent.vonAllmen@imt.unine.ch
Newsgroups: comp.os.vxworks
Subject: Beginner questions on VxWorks
Date: 29 Sep 92 14:31:20 GMT
Organization: University of Neuchatel, Switzerland

Hello!

Sorry for this beginner request but we are starting a new projet and we have
little time to make a choice. We are evaluating VxWorks:

We would like to answer the following questions:

	- Which types of processor are supported?
	- Is a VME driver included?
	- Which mass storage facility?
	- Any remote debugging?
	- Posix conformance?

We would be grateful if either we receive the answers or we are given
references about these OS comparisons/benchmarks.

Please e-mail answers to

X.400 :  C=ch; A=arcom; P=switch; O=unine; OU=imt; S=vonAllmen; G=Laurent
Internet-style :  Laurent.vonAllmen@imt.unine.ch

Any help mostly welcome. Thank you.

Laurent von Allmen
From: OWENS@lodtm.llnl.gov
Newsgroups: comp.os.vxworks
Subject: GreenSpring IP Serial Driver
Date: Fri, 2 Oct 1992 14:17 PDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

I recently acquired a serial I/O module (Industry Pack) from GreenSpring
Computers.  Has anyone written a driver for this or a similar RS 232
interface (it uses the 85C30 chip).

  Thanks,
  Doug Owens (owens@lodtms1.llnl.gov)
From: hwajin@iphasew.iphasew.com (Hwa-Jin Bae)
Newsgroups: comp.os.vxworks
Subject: Re: Locking Interrupts..
Date: 29 Sep 92 23:46:37 GMT
Organization: Interphase West, Santa Clara, CA
In-reply-to: zafer@bcars474.UUCP's message of 29 Sep 92 04:17:11 GMT

>>>>> On 29 Sep 92 04:17:11 GMT, zafer@bcars474.UUCP (Zafer Elbi) said:

Zafer> int lock = intLock();
Zafer> ..
Zafer> ..
Zafer> ..--->  Task switch
Zafer> ..
Zafer> intUnlock();

Zafer> If there is a task switch occurs in the middle of the interrupt
Zafer> routine, can the preempting task unlock the interrupts again?


i suppose the answer is yes, since anyone can call intUnlock() if they
want to but whether it is desirable to do so is another matter.  the
interrupt mask information is part of the task context -- in m68k
world, status register contains this info which gets saved and
restored per context switch.  what you may or may not want to do is to
disable the task switch (taskLock()/taskUnlock()) depending on whether
you're really concerned about locking out interrupts and not being
context switched out (which could alter the interrupt masks depending
on which task gets switched in).

	~hwajin
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Newsgroups: comp.os.vxworks
Subject: re: Intertask communication mechanisms
Date: Thu, 1 Oct 92 10:25:44 CDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

mitchell@aaec1.aaec.com (Andrew Mitchell) says:
 
>We developed a "Global" semaphore library for a multi-CPU chassis for
>vxWorks 4.

Are you able to post this or put it in the VxWorks archive?  Or
maybe refer to the contract you delivered this on (if it was
for one of the Services, and therefore maybe public domain)?

We thought about doing the same thing, but I thought you had to do
that in the Wind kernel, so I chickened out.  I've got the source,
but no guts.

What we did on the Mod Sim program was to allow only one secondary
CPU to interrupt the primary CPU.  We hacked sysMemTop so that it
fooled VxWorks into thinking the board had 64K less than it actually
had (at the top), then we used this memory to transfer commands
to the primary CPU and hit it with an interrupt.  Real primitive!

I'd also like to hear what you can tell us about UltraNet.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+