HDTenEightyP/NetNews huggingface dataset:
From: lachlan@dmp.csiro.au (Lachlan Cranswick)
Subject: Re: Is there a PICO Unix - dired / utree??
Organization: CSIRO Division of Mineral Products, Melbourne, AUSTRALIA
Date: Fri, 8 Jan 1993 06:31:19 GMT

bvaughan@sheps.Princeton.EDU (Barbara Vaughan) writes:

>In article <1993Jan7.063127.11766@dmp.csiro.au> lachlan@dmp.csiro.au (Lachlan Cranswick) writes:

>>You might also want to look into Xtree for UNIX.  If Xtree for
>>DOS is popular on your PCs, it should help protecting users
>>against the nuances of the UNIX command line.
>>We haven't got it going here because we are still trying to
>>get a demo copy on tape - at the moment XTREE 
>>Australia only have floppy
>>demo disks for SUN or SUN compatable machines.

>We have two free (anonymous ftp) programs that provide similar functionality:
>dired (sort of like Norton Commander) and utree (which sounds similar to
>xtree).  Both installed easiliy on our Suns.  

>However, PICO 1.5 provides much of the same functionality, with its "file
>browser".  It allows you to search for, rename, copy, move or retrieve
>into current document by cursor movement and single keystroke commands
>shown on the help bar.  You only see the file browser if you try to read
>in (^R) or write out (^O) a file.  Then you will see the option ^T, which
>normally invokes the speller, but during file operations invokes the file
>browser.

Would it be possible for someone to give a review of these
dired and utree programs.

My queries are, -  like xtree - do they use one keystroke commands
to copy, rename, delete, makedir  etc.  Also, can you highlight a file
then edit it (type "e" for edit); or type something 
like "x" to execute (xtreegold) and then
type in a command to run a program.  A nice feature of Xtree for
DOS is if you press up-arrow while doing a command like execute or rename
it gives you a list of the previous commands or file names you used
depending on what you are doing - i.e., - It is context sensative.
If you know how to use this feature - it is a big time saver.     

I know of a couple of users who use PICO as a file manager
as well - but its not really made (yet?) for this function.
Given what a brilliant job the programmers of PICO have done, a "full"
file manager incorperated with PICO would be a nice feature.

Thanks in advance,  Lachlan.

I'm going to do an archie search on these two programs
and try them out when I get back from my holidays.
It is supposed to be mid summer here but there has not been 
a day or 2 when it has now been raining or the threat of rain!!

Not the type of weather I like to go camping in and get 
back to nature.  Its either read news via modem, or watch sesame street
- AAARGH.
-- 
  Lachlan Cranswick  -  CSIRO             _--_|\  lachlan@dmp.CSIRO.AU
  Division of Mineral Products           /      \ tel +61 3 647 0367
  PO Box 124, Port Melbourne 3207        \_.--._/ fax +61 3 646 3223
  AUSTRALIA                                    v 
Newsgroups: biz.sco.general,comp.unix.sysv386
From: rodeen@buddha.ncc.umn.edu (Rick Odeen)
Subject: Re: 9 track (1/2") tape drive suggestions for SCO unix
Organization: Nutrition Coordinating Center, University of Minnesota
Date: Thu, 7 Jan 1993 16:32:35 GMT

In article <1993Jan07.014245.12675@pribal> jackl@pribal (jack lowry) writes:
>
>We need the ability to write nine track tapes under
>SCO UNIX running on a 486 EISA machine. 
>I have looked at the ads in the back of magizines and 
>found the 5 vendors listed below.
>
>Laguna Data Systems
>
>Can anybody relate any expierence good or bad that 
>they have had these or any other vendors. 

A friend of mine did business Laguna Data Systems about a year ago and
had a very bad experience with them, they basically stole his money and
lied to him and everyone else who he tried to involve.  I'd say stay
away from them.  Anyone who might be interested in the specifics of
his experiences should write to pberger@taiga.ncc.umn.edu (Peter Berger),
I'm sure he'd be glad to provide the details.

-Rick Odeen

-- 
"MINIX costs $169, but the license allows  | Rick Odeen 
making two backup copies, so the effective | Richard.J.Odeen-1@umn.edu 
price can be under $60."                   | rodeen@buddha.ncc.umn.edu 
         - ast@cs.vu.nl (Andy Tanenbaum)   |
Xref: sparky biz.sco.general:5019 comp.unix.sysv386:17699
From: watson@carssdf.UUCP (- Self Empl. Sys.Integrator)
Newsgroups: biz.sco.general,comp.unix.sysv386
Subject: Re: 9 track (1/2") tape drive suggestions for SCO unix
Date: 8 Jan 93 01:24:30 GMT
Reply-To: watson@carssdf.UUCP (John Watson -- Self Empl. Sys.Integrator)
Followup-To: biz.sco.general
Organization: John Watson (Self Employed System Integrator)


To: jackl@pribal

Mail bounced so I have to post instead.

Your solution is real simple, use OVERLAND DATA!

They are great and they understand 9 track tape for something
besides tar and cpio.  If one more person tells me to append
trailing ^Z^Z^Z or some such to the end of my data, and I have
to explain that I can read either the tape or the jiffy bag that
it came in I'm gona throw the phone out the window!  When I get
tapes from some IBM organization with lists of names to send mail
too, I don't get to talk to anyone, I just read the tape and 
make it work.

OVERLAND DATA works for me.  EMERALD with QUALSTAR was a mess.

Oh yes, I have a used Cipher F880 with (pertec?) interface suitable
for use with Overland Data TXi card.  If you wanna buy the interface
from Overland with Unix Drivers and the Drive from me (actually
my customer), let me know.  We're talking cheap here because the
drive is only 1600/3200, not 6250.  Great for writing tapes for others
to read, but not much good for random input tapes which these days
are 90% 6250.

John Watson       watson@carssdf.UUCP
Newsgroups: biz.sco.general
Subject: Re: compiling GNU programs
From: dstuart@talis4.UUCP (Damien S. Stuart)
Date: 4 Jan 93 17:05:53 GMT
Organization: ARINC Research Corp. Warner Robins, GA

In article <9212302046.aa12907@ohriman.ohriman.mi.org>, jep@ohriman.mi.org (John
Perry) writes:
|> 
|> 	I'm having problems with libg++ 2.3 as well.  This fails very
|> quickly.  I get to "ar gc libiberty.a", and then "true libiberty.a",
|> and then get a:
|> 
|> sh: syntax error at line 67: `end of file' unexpected.

This problem is in the Makefile.  The a couple of the routines for determining
local utilities (AR, AS, BISON, etc...) seem to be broke.  I just substituted
the actual pathname for these (instead of having the Makefile do it):

Before:
-------
# Flags to pass down to sub-makes -- please keep these in alphabetical order
FLAGS_TO_PASS = \
        "AR=$(AR)" \
        "AR_FLAGS=$(AR_FLAGS)" \
        "BISON=$(BISON)" \
 etc...

After:
------
# Flags to pass down to sub-makes -- please keep these in alphabetical order
FLAGS_TO_PASS = \
        "AR=/bin/ar" \
            ^^^^^^^
        "AR_FLAGS=$(AR_FLAGS)" \
        "BISON=/usr/local/bin/bison" \
               ^^^^^^^^^^^^^^^^^^^^
 etc...

Note: I did the above for both 'X11_FLAGS_TO_PASS' and 'TARGET_FLAGS_TO_PASS'.

That took care of the syntax error.  I had little trouble compiling libg++.a
under SCO 3.2.2.  SCO 3.2.4 was more difficult, especially CursesW.  I ended
up omitting the CursesW routines altogether.  Someday I may get back to it.
Like you, I compiled libg++.a just so I could compile groff 1.06.  I eventually
got there, though it wasn't too easy.

Hope this helps...

-- 
|\/\/\/|     Damien S. Stuart          |
|      |     Arinc Research Corp.      |   uunet!srg!talis4!dstuart
|    o o)    Warner Robins, Ga. 31088  |   dstuart@arrakis.robins.af.mil
C       _)   --------------------------+---------------------------------
 |   ___|    Opinions expressed are my own.
 |    /      So don't have a cow, man!
From: tps@jptcs.COM (Tim Sailer)
Newsgroups: biz.sco.general
Subject: Re: time command
Date: 4 Jan 93 05:09:07 GMT
Organization: JPT Computer Solutions
X-Newsreader: TIN [version 1.1 PL6]

Anthony P Lawrence (apl@world.std.com) wrote:
: There has got to be a simple answer for this, but it's got me
: stumped.
: 
: I'm sitting here playing with a 115K baud terminal. I wanted to
: see how it compares to the system console, so I did 'time lr /etc'
: on both the console and the terminal.
: 
: The console finishes first, as we would all expect.  But, 'time'
: reports LESS real, user and system time for the command run on
: the terminal.
: 
: The only rational explanation is that either the multiport card or the
: terminal (or both) are doing a lot of buffering so that 'time' thinks
: the command is complete when it actually isn't.  

Yup... that's it! BOTH (depending on what your terminal is) will buffer the
data burst from the bus. The mport card was specificly designed to grab
chunks of data at near DMA speeds as possoble, and then handle the serial
stream itself. The video card (unless it's one of the new S3 type cards -
I think.... haven't gotten to play with one yet) has to handle it 
1 byte at a time... (someone correct me if I'm wrong)

: 
: Now: I had never thought about the effects of buffering on 'time'.  And
: I can't honestly say that I've spent a lot of time thinking about it even
: now.  But this simple example shows that 'time' measurements can be 
: quite false... and makes me wonder about other 'time'd benchmarks...

True... just like drive specs.... 

-- 
Tim Sailer
JPT Computer Solutions - SCO Sales/Consulting/Administration and Mangling
PO Box 423 Mt Sinai, NY 11766
(516) 331-9001
From: ti@bazooka.amb.org (Ti Kan)
Newsgroups: biz.sco.general
Subject: Compiler wierdness alert...
Date: 9 Jan 93 20:11:17 GMT
Reply-To: ti@bazooka.amb.org (Ti Kan)
Organization: AMB Research Labs, Sunnyvale, CA.

Consider the following program:

----------------------------------
#include <stdio.h>

#pragma pack(1)
union foo {
	char d1;
	long d2;
};
#pragma pack()

struct bar {
	char a;
	char b;
	char c;
	union foo d;
};

main()
{
	struct bar x;

	/* display the relative offsets of struct bar members */
	printf("\t%d %d %d %d\n",
		(char *) &x.a - (char *) &x,
		(char *) &x.b - (char *) &x,
		(char *) &x.c - (char *) &x,
		(char *) &x.d - (char *) &x);
}
----------------------------------

Program output (Compiled with cc on 3.2v2 DS or or gcc 2.2.2):

	0 1 2 4

Program output (Compiled with cc 3.2v4 DS, or rcc on both 3.2v2 DS
and 3.2v4 DS):

	0 1 2 3

So, with cc on 3.2v4 or rcc in both versions, the compiler does not put
a pad byte after field "c" in struct bar, whereas with cc on
3.2v2 DS or gcc, it does.

What significance is there?  Well, for most applications writers
there isn't a problem, as long as all modules that use this structure
are compiled with the same compiler.  There will be a problem if you
are going to be mixing object files or libraries compiled with different
compilers.

For device driver writers, there is definitely a problem.  If there
is a kernel structure defined as such, and the kernel was compiled with
a different compiler than yours, then there is a serious bug.

Guess what, there is exactly such a case.  In /usr/include/sys/scsi.h,
on both SCO 3.2v2 and 3.2v4, there is a "scsi_io_req" structure which
contains a subfield "union scsi_cdb".  The starting offset of this
union varies depending upon which compiler you use.

It appears that the SCO 3.2v4 kernel is compiled with the 3.2v2
Dev Sys compiler, so if you compile a SCSI device driver using the
3.2v4 DS compiler, you're in for a nice surprise.

Of course there is a workaround, just by explicitly inserting a
pad byte into the structure before the scsi_cdb union will solve this
particular case.  But how many other similar situations are there?

I don't know if there is an ANSI standard or somesuch that dictates
the correct compiler behavior in this scenario, but SCO has definitely
introduced an incompatibility between the cc compiler between 3.2v2 DS
and 3.2v4 DS.

Just thought I'd make everyone aware of this... I found out the hard
way.

-Ti
-- 
    ///  Ti Kan                vorsprung durch technik
   ///   AMB Research Laboratories, Sunnyvale, CA. USA
  ///    ti@amb.org
 //////  ...!{decwrl,synopsys,tandem,tsoft,ultra}!sgiblab!bazooka!ti
///      ...!{uunet,sun,apple,sco}!altos!bazooka!ti
From: sl@wimsey.bc.ca (Stuart Lynne)
Newsgroups: biz.sco.general
Subject: Re: cache design parameters
Date: 12 Jan 93 00:40:59 GMT
Organization: Wimsey Information Services

In article <9301110917.aa06496@scoke.sco.COM> Bela Lubkin <belal@sco.COM> writes:
>Bela> Any specific example is going to be a brand name, no?  ;-}
>
>Anyway, I don't see anyone advertising set-associative caches.  Do you?

These are almost certainly intimately tied up in the supporting chip
set. I.e. if you use the Intel chipset you will probably be tied into
the cache design it supports. Same with C&T, Opti and SIS. 

It would be worth our while to try and track down some documentation
on each chipset and see what they say about cache design. I did at
one point a year or two back have some info on C&T's chip set. But
can't seem to find it.

-- 
Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
Newsgroups: biz.sco.general
From: vancleef@netcom.com (Henry van Cleef)
Subject: Re: Three compilers compared on Unix 3.2v4 (long)
Organization: Netcom--posted from Andover, Mass.
Distribution: biz
Date: Tue, 5 Jan 1993 05:48:03 GMT

In article <1i9521INN5o7@mailgzrz.TU-Berlin.DE> gb@buran.fb10.tu-berlin.de (Guenter Becker) writes:
>This reflects my experience: compiling the same source with sco  
>(microsoft) cc and gcc does not make much difference in compilation time  
>and execution time. However, my test source (about 300 k motif  
>application) did a lot of malloc and free. When I changed to gcc's inline  
>alloca in some critical portion of the code, this yielded some 15 %  
>improvement in execution time. Microsoft cc does not include alloca. I  
>think, it would be nice to have it. Though it is not in the standard, it  
>is not specific to gcc; e. g., on suns, it is available. Does anyone have  
>alloca for sco cc ?
>
There is an alloca in libPW.a.  However, you could compile the GNU
alloca and link with it.

-- 
Hank van Cleef  vancleef@netcom.com vancleef@tmn.com  Andover, Mass.
Unix systems consultant---kernel, device drivers, networking, X11
SysV, BSD, Sun, Ultrix, AIX, SCO. Porting a specialty. 
	     The Union Institute  History of Science
Newsgroups: biz.sco.general
From: news@choreo.ca (Choreo NetNews Administration Account(Ottawa))
Subject: Re: UUCP over TCP/IP
Organization: Choreo Systems, Ottawa Canada
Distribution: biz
Date: Tue, 05 Jan 1993 03:57:18 GMT

In article <C0Cx7x.3KJ@wimsey.bc.ca> sl@wimsey.bc.ca (Stuart Lynne) writes:
>In article <C0Cv0z.4EK@norstan.com> sfrazier@norstan.com (Superuser) writes:
>>I am trying to get uucp of TCP/IP to work.  When I do a uucp, the job
>>get's que'd.  I run uucico and it tells me I have no device.
>>
>>Can anyone tell me what I am doing wrong?
>>
>>Here is my Devices file:
>>
>># where the Systems entry looks like
>># scoast Any TLI,e Any \002\000\001\000\226\176\004\026\000\000\000\000\000\000\000\000
>>#	(The third field in Systems matches the first field in Devices)
>
>Do you really have the "#" comment char at the beginning of the entry?
>
>I don't think the TLI version is recommended either. Something like the following
>in /usr/lib/uucp/Systems:

Quite right ! Use of the TLI uucp is discouraged.
>
>  xxx.yyy.com Any TCP,e Any -  ogin:-BREAK-ogin:-BREAK-ogin: LOGINID ord: PASSWD\r
>
>is what you want. Change LOGINID and PASSWD to your login id and passwd.

Not quite.  Remove the -BREAK- sequences, as they can on occassion cause you
some heartache.
>
>And in /usr/lib/uucp/Devices:
>
>  TCP TCP,e   -       Any     TCP 
>
>-- 
>Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
>Wimsey Information Technologies ................... moderator biz.sco.binaries
>uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
>PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd


Newsgroups: biz.sco.general
From: sfrazier@norstan.com (Superuser)
Subject: UUCP over TCP/IP
Organization: Norstan Communications - Columbus, Ohio
Distribution: biz
Date: Tue, 5 Jan 1993 00:36:34 GMT

I am trying to get uucp of TCP/IP to work.  When I do a uucp, the job
get's que'd.  I run uucico and it tells me I have no device.

Can anyone tell me what I am doing wrong?

Here is my Devices file:

#	@(#) Devices 23.3 91/11/01 
#
#	Copyright (C) 1988-1991 The Santa Cruz Operation, Inc.
#		All Rights Reserved.
#	for purposes authorized by the license agreement provided they include
#	this notice and the associated copyright notice with any such product.
#	The information in this file is provided "AS IS" without warranty.
#
#	(The third field in Systems matches the first field in Devices)

# Access a TCP/IP connection to a system using the TCP protocol interface
# TCP TCP,e   -       Any     TCP 	<port on remote machine, usually 540>
TCP TCP,e   -       Any    TP 540
#
# where the Systems entry looks like
# gregory Any TCP Any -  ogin:-BREAK-ogin:-BREAK-ogin: christin
#	(The third field in Systems matches the first field in Devices)

# Access a TCP/IP connection to a system using the TLI protocol interface
# TLI	inet/tcp	-	Any	TLI	\D	nls
#
# where the Systems entry looks like
# scoast Any TLI,e Any \002\000\001\000\226\176\004\026\000\000\000\000\000\000\000\000
#	(The third field in Systems matches the first field in Devices)




Here is my inetpd.conf file:


#      @(#)inetd.conf	5.2 Lachman System V STREAMS TCP  source
#
#	System V STREAMS TCP - Release 4.0
#
#   Copyright 1990 Interactive Systems Corporation,(ISC)
#   All Rights Reserved.
#
#	Copyright 1987, 1988, 1989 Lachman Associates, Incorporated (LAI)
#	All Rights Reserved.
#
#      SCCS IDENTIFICATION
ftp	stream	tcp	nowait	NOLUID	/etc/ftpd	ftpd -d -l
telnet	stream	tcp	nowait	NOLUID	/etc/telnetd	telnetd
shell	stream	tcp	nowait	NOLUID	/etc/rshd	rshd
login	stream	tcp	nowait	NOLUID	/etc/rlogind	rlogind
exec	stream	tcp	nowait	NOLUID	/etc/rexecd	rexecd
finger	stream	tcp	nowait	nouser	/etc/fingerd	fingerd
uucp	stream	tcp	nowait	NOLUID	/etc/uucpd	uucpd
# Enabling this allows public read files to be accessed via TFTP.
tftp	dgram	udp	wait	nouser	/etc/tftpd	tftpd
# This is the more secure method, since only files from /tftpboot can
# be accessed via TFTP.   This must be root in order to do the chroot
# to /tftpboot.  /tftpboot must be created by hand.
#tftp	dgram	udp	wait	root	/etc/tftpd	tftpd -s /tftpboot
-- 
Norstan Communications, Inc.        | Steven E. Frazier
8101 N. High Street Suite 100       |---------------------------------------
Columbus, OH   43235                | Local : sfrazier
Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com
From: alexl@alvarez.COM (/dev/null)
Newsgroups: biz.sco.general
Subject: 9 track (1/2") tape drive suggestions for S
Date: 8 Jan 93 02:26:35 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: scogen@xenitec.on.ca
Precedence: bulk


.>   We need the ability to write nine track tapes under
.>   SCO UNIX running on a 486 EISA machine. 
.>   I have looked at the ads in the back of magizines and 
.>   found the 5 vendors listed below.

.>   Laguna Data Systems
        I bought some Hardware from them no complants.

.>   NovaStor Corp
        Never done bussiness with them.

.>   Qualstar
        Ahh, Qualstar, One of our customers needed a 9 track 
drive and he had heard of Qualstar, so I searched and found them 
in California. I spoke to Ron Ford, Good Guy, he sold me the 
drive. Drive was shipped UPS red, didn't work. NO PROBLEM they 
sent me another one. Again didn't work, I went though 4 drives 
finally the one that works is their top of the line drive. They 
were VERY FAIR, they gave me full credit for the original drive 
and never charged me to send the others, and I got a great deal 
on the one we have now. I recomend them, if their product didn't 
work they didn't spend time pointing the finger at someone else, 
they responded quickly and got the job done. We lost some time 
with the situation but it was taken care of. I would definatly 
use them again...


.>   Overland Data.
        Again, very helpful and knowledgable. these guys know 
their stuff. I had a problem, got on with tech support and it was 
fixed in 5 minutes, (simple problem, my error). I have and will 
use them again.


.>   CONTECH
        Not familiar with them..

.>   Can anybody relate any expierence good or bad that 
.>   they have had these or any other vendors. 
.>   We need a reliable setup with 1600 BPI capability and 
.>   device driver support for standard SCO UNIX utilities
.>   such as tar, cpio, and dd. 
                The drivers are usually SCSI and use Stock SCO 
devices, or they create their own devices that all the apps can 
use. Including C-TAR.


.>   Approaching this from a different light could this be as
.>   simple as finding a SCSI 9track (1/2") tape drive such as
.>   a CIPHER and with the correct cable hooking it to for example
.>   a ADAPTEC 1742 and have it work?
                Thats the way the Qualstar works in the situation 
above.


.>   Please use the complete path listed below as this system is
.>   too new to be listed in the maps or call me 9-5 est at
.>   800-776-2454 thanx, jack

.>   Jack Lowry
.>   wb3ffv!pribal!jackl

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /  ) //            _//                   Alexander Lopez
 /--/ // _  _.,      /    _____   _  __.   Alex Alvarez and Associates
/  (_</_</_/ /\_    /___ (_) /_)_</_/  |_  alexl@alvarez.COM
                            /         (|   305-649-8900
From: brian@ilinx.wimsey.com (Brian J. Murrell)
Newsgroups: biz.sco.general
Subject: Re: CDROM problems
Date: 11 Jan 93 04:07:34 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text/plain; charset=US-ASCII
Cc: scogen@ilinx.wimsey.com
Content-Length: 1241
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

As enscripted by Randy Suess:
> 	Well, I gave up and stuck a NEC 82 (also not officialy supported!)
> 	in there and it works fine.  Can anyone explain why a particular
> 	SCSI cdrom drive is not supported?  We are not talking about a
probally because it hasn't been tested yet.  There is a giant plethora of 
stuff out there that works but is not supported (i.e. hasn't been
tested!)
> 	pseudo scsi drive like a lot of the Sony's but one that seems
> 	to follow all the specs properly.  The usual case, as in earlier
> 	releases of OS/2, the driver has imbedded in it the manufacter 
> 	code  returned by the drive.  Common practice was to binary
> 	edit the driver and patch in your name, and it all worked.
> 	Same thing with some stupid AT&T scsi hard disk drivers that
> 	only worked with their drives before patching.  However, I cannot
> 	find any .o or space.c file in all of pack.d that has cdrom
> 	ids embedded.

brian

-- 
Brian J. Murrell                                      brian@ilinx.wimsey.bc.ca
InterLinx Support Services, Inc.                      uunet!van-bc!ilinx!brian
North Vancouver, B.C.                                             604 984 2545
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD