HDTenEightyP/NetNews huggingface dataset:
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinntp!psinntp!polari!lampi%polari.online.com@ucbvax.Berkeley.EDU
Subject: Re: Versatec plot file format
Organization: R Squared, Redmond, WA (206) 883-3116
Distribution: fj
Date: Sat, 12 Sep 1992 00:21:00 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <199209092210.AA29243@pan.ssec.honeywell.com> thompson@PAN.SSEC.HONEYWELL.COM ((jt) John Thompson) writes:
>
>
>> I'm trying to find out the file format that the Versatec electrostatic
>> plotters (eg, v80, v7236) use (I'm assuming it's the same for all size
>> plotters).  In other words, if I wanted to print a raster file to a
>> versatec using 'prf -transparent', what should the file look like?
>
>The basic format is identical -- it's a stream of bits that are on (black)
>or off (white).  You must put out enough bytes to fill the entire line --
>there's no 'carriage-return' option.
>
>If you're close to this, you might simply be missing the (previously 
>undocumented) prf switch.  Try "prf filename -transparent -vers_pp plot"
>and see what you get.  By default, stuff is sent to the Versatecs in 'print'
>mode unless one of the filters (for a bitmap, for example) toggles it.  If
>you use -transparent, there's no toggle done, and you get that default, giving
>you yards and yards and yards of paper (talk about your 15yard penalty!)
>
The raster scan lines are 2112 bits across for a Versatec V80. The files
are (or at lest used to be) REC formatted (4 bytes length + data).

That is, if my memory serves me (This is from waayyy back in '83 :-) when
I had to write GPR (when there was no such thing) routines for a V80 on
a DN-400.


-- 
-----
+-+  Michael Lampi       lampi@polari.online.com
|R|  R Squared           16398 NE 85th St., Suite 101, Redmond, WA 98052
+-+                      (206) 883-3116       fax (206) 883-2676
Newsgroups: fj.mail-lists.apollo
From: sol.ctr.columbia.edu!usc!hacgate!solaria!bill@lll-winken.llnl.gov  (Bill Neisius)
Subject: Re: rz/sz doesn't work on our machines
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Wed, 9 Sep 1992 19:44:38 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Kevin Gallagher (kgallagh@digi.lonestar.org) wrote:
: In article <1992Sep04.184127.17533@edsi.plexus.COM> chuck@edsi.plexus.COM (Chuck Tomasi) writes:
: I compiled the rz/sz sources under Domain/OS 10.3.0.8 on a DN3550 in SYSTYPE
: bsd4.3.  I connect from my PC at home to my Apollo through a DECserver to a
: VAX (running VMS) and from the VAX to the Apollo via telnet.  The connection
: turns out to be very robust.  The modem runs at 2400 baud.  On the PC, I use
: Crosstalk Mk.4, the latest version,  using the build-in implementation of
: ZMODEM. 
: 
: I can upload files from my Apollo node to my PC by invoking the sz command at
: the Unix shell prompt.  The transfer rate is outstanding at around 232
: characters per second.  However, I can't get the rz command to download files
: from my PC to my Apollo.  I do suspect the ZMODEM implementation in Crosstalk
: is, at least, partially at fault, but I can't be sure.  The version of Kermit
: we have installed doesn't handle downloads to the Apollo as well as it handles
: uploads.  We have to use smaller packets when downloading than when uploading,
: and download failures happen often.  So it is possible that there is something
: about the Apollo that causes problems here.

I also connect my PC through a VAX to my Apollo.  However, I found that
the only way I could send files from the Apollo to the PC was to use
the '-e' (escape control characters) option. I assume that without it
the VAX in the middle is XOFF'd and communication is blocked.  Unfortunately,
although the GSZ I use on the PC can receive escaped control characters,
it doesn't seem to be able to send them... transferring a file from PC
to Apollo requires storing it on the VAX then ftp'ing to Apollo...

So how are you able to get 232 cps?  Best I get (with the '-e' option)
is about 180 cps...

Bill Neisius
bill@solaria.hac.com
Newsgroups: fj.mail-lists.apollo
From: sun-barr!west.West.Sun.COM!cronkite.Central.Sun.COM!rmtc.Central.Sun.COM!berliner@ames.arc.nasa.gov  (Brian Berliner)
Subject: Re: rsh dump
Organization: Sun Microsystems, Inc.
Distribution: fj
Date: Sat, 12 Sep 1992 17:31:04 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In <1992Sep11.221138.22934@auto-trol.com> jacsch@auto-trol.com (Jack Schetrom) writes:
>This has occurred on more than one sparc station running
>4.1.2 (or from an HP/apollo node running X-windows) where
>the dump requires more than one ctape to complete
>the dump. If the command is run on the node where the ctape
>is physically attached, it also fails.
>If the coomand does not require more than one ctape for the
>dump, all runs OK.

>It seems that the problem lies in how the display is handled.

>Does anyone know of a patch/workaround/fix for this?

The only "fix" for this is to purchase the Sun Backup Copilot 1.0 product.
It includes a dump replacement program that knows how to communicate with a
new networked operator monitor.  When your remote dump hits end-of-tape, it
doesn't belch as you describe.  Instead, it connects to the only display it
has (the network monitor, that is) and you can answer the prompts from
there.  The same holds true for the restore program.  Backup Copilot, of
course, includes much more than this.

	-Brian
Newsgroups: fj.mail-lists.apollo
From: mcsun!sunic!ugle.unit.no!lise.unit.no!vindvad@uunet.uu.net  (Hans Vindvad)
Subject: Re: X Kernel for Apollos
Organization: Norwegian Institute of Technology
Distribution: fj
Date: Sun, 13 Sep 1992 10:48:49 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <Bu9JK8.1rq@cs.bham.ac.uk>, dma@cs.bham.ac.uk (Denis Martin Anthony) writes:
 > I wish to make some Apollo workstations X terminals to a new HP
 > network. Has anyone out there already done this? Do you perchance have
 > an X Kernel available?
 > 
 > Any info welcomed.
 > 
 > 
 > 
 > -- 
 > Denis

We are using X11R5 from  FTP:  flipper.pvv.unit.no
                         DIR:  /pub2/apollo

Hans Vindvad
vindvad@imf.unit.no
Newsgroups: fj.mail-lists.apollo
From: dog.ee.lbl.gov!overload.lbl.gov!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!network.ucsd.edu!sdcc12!sdcc13!svaldez@ucbvax.Berkeley.EDU
Subject: Apollo color monitors = VGA ?
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Wed, 9 Sep 1992 03:31:12 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


    Does anyone know what the specs are on Apollo color monitors?  I
don't have any exact model numbers so if there are differences
please let me know.  The Apollo large-screen color monitor's that
I used over the summer had the three BNC connectors for the RGB
signal.  I assume then that they are all the same?

    I'm asking because I'd like to try and interface my PC's S-VGA
card with an Apollo monitor if possible.  Would a 15-pin to BNC
cable be all I need?  Could someone with the specs tell me what 
the maximum horiz/verti frequencies, sync, and resolution for these
are?   

    A lot of questions but any kind of help would be very
appreciated!

svaldez@sdcc13.ucsd.edu 
Newsgroups: fj.mail-lists.apollo
From: sun-barr!cs.utexas.edu!sdd.hp.com!scd.hp.com!hplextra!otter.hpl.hp.com!hpltoad!hpopd!hpwin052!dan@ames.arc.nasa.gov  (Dan Bennett)
Subject: Re: Colour maps on DN4500 (again??)
Organization: HP Response Centre, Berkshire, England.
Distribution: fj
Date: Tue, 8 Sep 1992 10:28:07 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Hi,

Just to point out that the rs -f and rs -o business is probably your
solution. At 10.2 (I think) colour map management was changed to accommodate
the 400 series PVRX displays (true colour emulation). The issue is that
although lcm -p filename DOES load the colourmap according to your colourmap
file, the allocation of WHICH colour does WHAT in the slots 1-15 as used
by the Display Manager. rs -o seems to be the thing that reorders the slot
allocation as expected.

Dan Bennett.
Newsgroups: fj.mail-lists.apollo
From: olivea!spool.mu.edu!cserver!edsi!chuck@ames.arc.nasa.gov  (Chuck Tomasi)
Subject: rz/sz doesn't work on our machines
Organization: Enterprise Data Systems Incorporated, Appleton WI
Distribution: fj
Date: Fri, 4 Sep 1992 18:41:27 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

We're running mostly DN3550/DN4500/DN5500 machines on our site (with a
few 425Ts) under Domain/OS 10.3.5.  We compiled the rz/sz sources with
SYSTYPE=sys5.3 and everything appeared to go alright.  The problem is
that they don't work.  The same sources work fine from an HP-UX v8.0
machine however it seems that something is being blocked or trapped when
we invoke them from the Domain machines.

Let me explain.  We are working on a Mac from home with software which
supports auto-zmodem downloading.  From the HP-UX machine the zmodem
init string initiates the zmodem transfer and everything goes as
expected, however with the same command is issued from the Domain
machine you see the same portion of the init string, but you also see
things like the file name, CRC, and a few other things.  This is not
normally seen!

This happens whether we are directly connected to the sio line or
telnetted in from the HP on a psuedo tty so I doubt whether it has
anything to do with the way Apollo handles the sio lines.

Do we need some compiler switch, header file, or different SYSTYPE to
get it to work or do we need to play with stty or something equally as
mysterious?
-- 
Chuck Tomasi             |     "It's my job to help
chuck@edsi.plexus.COM    |      but I don't have to like it."
spool!cserver!edsi!chuck |                    -Dr. Crusher, "I, Borg"
------<Enterprise Data Systems Incorporated, Appleton Wisconsin>------
Newsgroups: fj.mail-lists.apollo
From: olivea!gossip.pyramid.com!pyramid!ctnews!88opensi!sartin@ames.arc.nasa.gov  (Rob Sartin)
Subject: Re: Strange packaging technique
Organization: 88open Consortium Ltd., San Jose
Distribution: fj
Date: Sat, 5 Sep 1992 21:07:47 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <0ylnpl#.snow@netcom.com> snow@netcom.com (Tim Szeliga) writes:
>"HP P/N 19511-80014".  

Ahh, yes, the Eagle shipping braces.  I got one that had a defect
(knot hole) and we called up to see if there was a repair/replace kit
or service manual.  We were aghast to discover that there was NO SUPPORT
for this HP product!

Rob
Newsgroups: fj.mail-lists.apollo
From: jrp (J.R.Penny) <jrp%telford@aberdeen.ac.uk>
Subject: Soln. to colour map problem
Posted-Date: Wed, 9 Sep 92 12: 25:54 MET
Organization: Electrotechnical Laboratory, Tsukuba Science City
X-Email: j.r.penny@aberdeen.ac.uk
Distribution: fj
Date: Wed, 9 Sep 1992 11:25:54 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>
X-Mailer: ELM [version 2.3 PL11]
Via: uk.ac.aberdeen; Wed, 9 Sep 1992 12: 30:36 +0100
X-Phone: 0224-272563


The connections to the monitor at the back of the Apollo were pushed in the wrong way.

The person in question insisted that the colours suddenly changed while using the machine.
This should obviously have been interpreted as he suddenly noticed that the colours had changed!
Perhaps I should ignore what I'm told happpened/what the problem is/.....


Thanks to those who replied.

Jon Penny
j.r.penny@aberdeen.ac.uk
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen.uiowa.edu!mtpins@ucbvax.  (Michael T Pins)
Subject: Re: rz/sz doesn't work on our machines
Organization: University of Iowa, Iowa City, IA, USA
Distribution: fj
Date: Sat, 12 Sep 1992 04:15:23 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

chuck@edsi.plexus.COM (Chuck Tomasi) writes:

>We're running mostly DN3550/DN4500/DN5500 machines on our site (with a
>few 425Ts) under Domain/OS 10.3.5.  We compiled the rz/sz sources with
>SYSTYPE=sys5.3 and everything appeared to go alright.  The problem is
>that they don't work.  The same sources work fine from an HP-UX v8.0
>machine however it seems that something is being blocked or trapped when
>we invoke them from the Domain machines.

>Let me explain.  We are working on a Mac from home with software which
>supports auto-zmodem downloading.  From the HP-UX machine the zmodem
>init string initiates the zmodem transfer and everything goes as
>expected, however with the same command is issued from the Domain
>machine you see the same portion of the init string, but you also see
>things like the file name, CRC, and a few other things.  This is not
>normally seen!

>This happens whether we are directly connected to the sio line or
>telnetted in from the HP on a psuedo tty so I doubt whether it has
>anything to do with the way Apollo handles the sio lines.

>Do we need some compiler switch, header file, or different SYSTYPE to
>get it to work or do we need to play with stty or something equally as
>mysterious?

I compile most everything, including zmodem, using SYSTYPE=bsd.
The only changes I made to the code was to add a few casts to void
to make it ANSI compliant.
I've had it running as such for months without a problem.

-- 
*****************************************************************************
* Michael Pins                |   Internet: amigapd@isca.uiowa.edu          *
* ISCA's Amiga Librarian      |         #include <std.disclaimer>           *
*****************************************************************************
Newsgroups: fj.mail-lists.apollo
From: mcsun!uknet!siesoft!athen!ztivax!paulisch@uunet.uu.net  (Dr. Frances Paulisch)
Subject: XDR on Apollos?
Organization: Siemens AG in Munich, W-Germany
Distribution: fj
Date: Wed, 9 Sep 1992 11:56:42 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

I have an application which uses the XDR routines to save data in an 
efficient, (supposedly) machine-independent binary format.  Upon porting 
it to our Apollo workstations (DN3000), we noticed that the XDR include 
files and system calls are not available on our Apollo systems.

Does anyone know whether the XDR routines are, in fact, available on 
Apollo? If not, does anyone know of public-domain version of the 
XDR-routines which we could then port ourselves?

Many thanks in advance

Frances Paulisch		paulisch@ztivax.zfe.siemens.de
Siemens AG
ZFE BT SE 3
Otto-Hahn-Ring 6		Tel. +49/89/636-42289
D-8000 Muenchen, FRG		Fax. +49/89/636-40898
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!polari!lampi%polari.online.com@ucbvax.Berkeley.EDU
Subject: Call for HW/Peripherals SIG Members
Organization: R Squared, Redmond, WA (206) 883-3116
Distribution: fj
Date: Fri, 4 Sep 1992 18:37:00 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

At InterWorks the Hardware and Peripherals SIG got off to a good start. We're
planning to produce articles for "The Works" on such hot topics as who has
what products for HP, HP/Apollo and Apollo computers, which products work
(according to *real* users), and in what directions HP should head with its
various products (e.g., increasing disk logical volume size from 4GB to 2TB,
for both HP-UX and Domain/OS; *supporting* - not just working with - 8mm
tape drives and 1/4" tape drives on HP-UX on 400's, 700's and 800's; etc.).

We need more people to commit to being active in this SIG over the next
year in order for it to be a 'valid' InterWorks Special Interest Group.

Please send your name, contact information, etc., to David Krowitz at
quake.mit.edu!krowitz or to me at lampi@polari.online.com

Thank you!

-- 
-----
+-+  Michael Lampi       lampi@polari.online.com
|R|  R Squared           16398 NE 85th St., Suite 101, Redmond, WA 98052
+-+                      (206) 883-3116       fax (206) 883-2676
Newsgroups: fj.mail-lists.apollo
From: thompson@pan.ssec.honeywell.com (jt -- John Thompson)
Subject: re: diskless 425e off 425s
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Thu, 10 Sep 1992 14:38:11 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>



> I am trying to run a diskless HP/Apollo 425e off a HP/Apollo 425s.
> The OS on the 425s is SR 10.3.4. We also have a diskless 425t off the
> same 425s using the token ring. Now the 425e only has ethernet. When
> ...
> (So the ethernet on the 425s seems to be OK.)
> However, the principle network on the 425s is token ring.
> 
> My question is:
> 
> Given the token ring as the principal network and the ethernet as
> the secondary network, is it possilbe to boot the 425e and the 425t
> off the 425s at the same time? (There is no problem to boot the 425t 
> as it stands now.)

Not as you currently have it.  If you changed the 425t and the 425s to
have the ethernet as their primary networks, then you could boot the
425e and 425t off the 425s system.

I've known it for a long time, and heard it for a long time, but until today,
I don't remember ever SEEING that you couldn't boot diskless along an alternate
network.  However...  in "Planning Apollo Networks and Internets", page 12-1
(in the -A01 revision anyway), they have a NOTICE:
    Apollo nodes _cannot_ boot from partners on other networks in the
    internet, so plan to locate diskless nodes and their partners on the
    same network.


> To boot the 425e off the 425s, we tried to switch the 
> principal network to ethernet. Then the 425s did not boot. 
> (Well, it went through all the self-tests, loaded the OS and the 
> local files. However, the window did not come up.)
Can't say much on this except "it should work".  We have done it with our
425t nodes a fair amount w/ no real problems.  You might want to try removing
the 'hint_file' and 'null_hint_file' from `node_data, and make sure that there
isn't anything it your bootup that would give you grief (can't think of anything
offhand, myself).


-- jt --
John Thompson
Design Services Engineer / Sys-Admin
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

If you're not part of the solution, you're part of the precipitate.
*************************************************************************
* This e-mail correspondence is a work of fiction.  Any similarity      *
* between the views presented and actual views, personal or corporate,  *
* living, dead, or still to be conceived, is pure coincidence.          *
*************************************************************************

Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!umn.edu!noc.msc.net!uc.msc.edu!apctrc!shimoda!zrde05@ucbvax.Berkeley.EDU  (Robert D. Ess)
Subject: Registry
Organization: Amoco Production Company, Tulsa Research
Distribution: fj
Date: Tue, 15 Sep 1992 13:30:45 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Have any Domainites written and have available any tools for registry administration
that can be executed by Joe User with having to be the rgy owner and use edrgy? I
will summarize. Thanks




                                  --- * ---
Robert Ess                                      voice   : 918-660-3638
Computing Research                              fax     : 918-660-4163
Amoco Production Research                       email   : ress@trc.amoco.com
                                  --- * ---

    "Jesus saves...but Gretski gets the rebound, he shoots, he scores!!"
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!swrinde!network.ucsd.edu!munnari.oz.au!metro!maths.su.oz.au!szabo_p@ucbvax.Berkeley.EDU  (Paul Szabo)
Subject: 425e: diskless -> disked ?? HELP
Organization: Mathematics, University of Sydney
Distribution: fj
Date: Mon, 7 Sep 1992 00:37:30 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

We have recently bought a couple of 425e's. Seeing HP's prices for things
like disks and memory, we decided to purchase 'minimum-configuration'
machines, with the idea of adding third-party bits-and-pieces.

I am having some trouble creating a disked 425e. I can easily plug in the
disk: the power supply cables are in place, the SCSI connector is there.
(The SCSI cable I used is a straight-through cable: connects pin 1 on one
connector to pin 1 on the other, same as in a DN2500.) The problem is
probably not one of terminators: the terminators are in place on the (only)
disk drive; it does not matter whether I plug in or not a terminator at the
back of the machine (into the external SCSI interface). The problem is
unlikely to be the type of disk I used: I also tried a Rodime drive (which
is a spare for a DN2500).

At the power-on (ROM) self test, the node displays

   HP98265 (SCSI S 32) at 14
       register test failed
   ...
   STORAGE DEVICE TESTS STARTED
   HP_$SCSI_SC_INIT: error
      SCSI bus init routine failed
      Storage Devices               - ABSENT

If I use 'DI N' and then 'TE' at the MD prompt, then it will also run the
loadable self test, at the end of which it will display

   -- Failure List --
      SCSI Device ID 7
      HP98265 (SCSI S 32) at 14

The disk used is jumpered to be SCSI ID 6 (and this last message does not
change if I re-jumper the drive to ID 5).

The node will not run: after 'DI N', 'EX anything' it will show the dots
while loading, then the line 'low high start', and then it just hangs.

I thought this might be caused by some jumper or setting on the 425e. But I
cannot see any jumpers that could be changed. (There are some jumpers next
to the ethernet connectors, but they are supposed to be the selector between
thick and thin ethernet. Also there are two DIP switches, but they must be
related to video mode selection: one switch is labelled 'C' and 'G' (color
or grayscale), the other '72' and '60' (Hertz).)

The 'CF' 'I/O Configuration', 'SCSI' command shows (correct?) default
values:
   Select Code      14
   Interrupt Level   4
   Parity            Y
   Bus Address       7
(The LAN SelectCode and InterruptLevel are 21 and 5, the HP Parallel ones
are 12 and 3).

(Obviously, if I unplug the disk the node will work properly.)


Can anyone help me to get the disk going?

Thanks in advance,

Paul Szabo - System Manager   //        School of Mathematics and Statistics
szabo_p@maths.su.oz.au        //   University of Sydney, NSW 2006, Australia
Newsgroups: fj.mail-lists.apollo
From: thompson@pan.ssec.honeywell.com ((jt) John Thompson)
Subject: re: Versatec plot file format
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Wed, 9 Sep 1992 22:10:51 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>



> I'm trying to find out the file format that the Versatec electrostatic
> plotters (eg, v80, v7236) use (I'm assuming it's the same for all size
> plotters).  In other words, if I wanted to print a raster file to a
> versatec using 'prf -transparent', what should the file look like?

The basic format is identical -- it's a stream of bits that are on (black)
or off (white).  You must put out enough bytes to fill the entire line --
there's no 'carriage-return' option.

If you're close to this, you might simply be missing the (previously 
undocumented) prf switch.  Try "prf filename -transparent -vers_pp plot"
and see what you get.  By default, stuff is sent to the Versatecs in 'print'
mode unless one of the filters (for a bitmap, for example) toggles it.  If
you use -transparent, there's no toggle done, and you get that default, giving
you yards and yards and yards of paper (talk about your 15yard penalty!)

Hope this helps a bit....
-- jt --
John Thompson
Design Services Engineer / Sys-Admin
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

If you're not part of the solution, you're part of the precipitate.
*************************************************************************
* This e-mail correspondence is a work of fiction.  Any similarity      *
* between the views presented and actual views, personal or corporate,  *
* living, dead, or still to be conceived, is pure coincidence.          *
*************************************************************************



Newsgroups: fj.mail-lists.apollo