HDTenEightyP/NetNews huggingface dataset:
From: sfrazier@vlink.com (Steven E Frazier)
Newsgroups: biz.sco.general
Subject: SCO IPX/SPX EFS
Date: 13 Dec 92 14:51:05 GMT
Reply-To: Steven E Frazier <sfrazier@norstan.com>
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
Content-Length: 398
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

What does the IPX/SPX EFS actually do?

Will it allow telnet sessions from a Novell work station or server.  If
so, what will it emulate?

What exactly does the IPX/SPX EFS do?

Thanks in advance.



-- 
Steven E. Frazier                            Voice: 614-785-7335
8101 North High Street - Suite 100           Fax  : 614-785-7337
Columbus, OH   43235                         sfrazier@vlink.com
Newsgroups: biz.sco.general,biz.sco.opendesktop,comp.unix.sysv386,alt.bbs.unixbbs
From: larry@news.rn.com (Larry Snyder)
Subject: Re: Trouble with FLOW CONTROL and FAS and rzsz
Keywords: modem fas flow usr courier sco odt
Organization: Gator Communications - Feeds-R-Us 219-289-3745 
Distribution: usa
Date: Thu, 17 Dec 1992 14:05:11 GMT

darkshot@rock.concert.net (Michael B Garrett -- Chudys) writes:

>I had this same problem with ODT 1.1, and nothing I tried helped. When we
>upgraded to 2.0, the problem went away- to the point that we can use
>rz/sz with cu (tilde + sz/rz) with no trouble- even MNP 5 works.

Maybe 1.1 didn't include support for complete hardware flow control?




-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
Newsgroups: biz.sco.general
From: forestie@dxcern.cern.ch (Jean-Philippe Forestier)
Subject: Card+driver for SCO UNIX
Organization: CERN European Laboratory for Particle Physics
Date: Mon, 14 Dec 1992 15:41:17 GMT

Hi everybody,

We would like to buy a card to be connected to a SCO Unix PC.
This card will be use for data acquisition.
The card must have at least 16 data acquisition lines (with a gain 1-2-5-10),
2 DAC (Digital Analogic Converter) (+ - 10v),
1 paralell input-ouput port,
the data acquisition rate must be around 100 HZ.

What we would like to do is to be able from Unix to communicate with
this (or those) card (s). We would like to be able to select a value 
on a given input line, to specify a gain on the acquisition line, to
read the DACs, to programm the DACs, to programm the timer and the paralell
port.

If you have any idea of the availability of such card and of the corresponding
driver, please let us know.

Many thanks in advance.

Jean-Philippe Forestier

PS: Please respond by email :

forestie@dxcern.cern.ch
From: jpr@jpradley.jpr.com (Jean-Pierre Radley)
Newsgroups: biz.sco.general
Subject: ps vs last
Date: 14 Dec 92 01:32:27 GMT
Reply-To: jpr@jpr.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Content-Length: 566
Precedence: bulk

Here's a curiosity:

% date
Sun Dec 13 20:20:03 EST 1992

% ps -fu umagpie
     UID   PID  PPID  C    STIME  TTY      TIME COMMAND
 umagpie  2098     1  9 20:01:15  A01      0:47 -uucico 

% last umagpie
User     Line  Device       PID    Login time       Elapsed Time Comments
umagpie  uA01  ttyA01       2098   Sun Dec 13 20:06      00:13   logged in

Note the five minute difference in the starting time in umagpie's process
2098, as seen by 'ps' vs. 'last'.

What's the story?

-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
Newsgroups: biz.sco.general
From: davidf@golem.waterloo.on.ca (David J. Fiander)
Subject: Re: Hiding machines in mmdf
Date: Fri, 18 Dec 1992 12:23:08 GMT

According to dkazem@nas.edu (Don Kazem):
>
>I am only running smtp and not UUCP and the offending line is the Return-Path
>line.
>It actually comes out as:
>
>Return-Path: dkazem@mailagent.nas.edu.

I don't have enough information to answer your question now.
On what machine is this "Return-path" being seen?  The
return-path is generated by the machine which puts the message
into the end recipient's mailbox.  If you are seeing this on
your SCO box, then I'll have to some exploring, otherwise I'm
willing to point the finger at somebody else.


>MLDOMAIN edu
>MLNAME nas
>MLOCMACHINE mserve
>
>I tried this and rebuilt the database, but then when I manually ran the deliver
>command
>mmdf did not deliver any of the messages. When I undid their suggestion, it
>worked again.
>Any thoughts, comments, and/or suggestions will be greatly appreciated.

That's because they might not have told you that when you do
this, you also have to change your local.chn file to contain
the line

	nas.edu:	mserve.nas.edu

As well, if you have more than one or two machines in the
domain nas.edu, then there is more work that has to be done.

- David
Newsgroups: biz.sco.general
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: xx (getch??)"
Organization: Celestial Software, Mercer Island, WA
Date: Mon, 14 Dec 1992 17:10:27 GMT

In <9212140809.aa04144@xenitec.xenitec.on.ca> Stefan Hippler <hippler@conica.mpia-hd.mpg.de> writes:

:Hi,
:I'm looking for a getchar() like function (getch) which does not wait for
:a line terminator. I know that there's a similar function available within
:the curses package but I cannot use it. Does SCO Unix provide a similar
:function which reads without blocking from a serial line?
:Any help welcome.

I assume that you're looking for something that can be used from
a shell script, not a C function.  Here are two short files,
getc, and askyesno.  getc is included with the '.' construction
under /bin/sh or /bin/ksh and loads the getc function.  askyesno
is something that I will call from another script, again using
the . function to ask whether you really want to run $progname.

The getc function is basically from one of the FAQs (I forget
which one offhand).

:
getc() {
	echo "\n$* [ ]\b\b\c">&2
	stty raw
	reply=`dd if=/dev/tty bs=1 count=1 2>/dev/null`
	stty -raw
	echo "" >&2
	echo $reply
}

Bill
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  getc askyesno
# Wrapped by root@camco1 on Mon Dec 14 09:07:01 1992
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'getc' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'getc'\"
else
echo shar: Extracting \"'getc'\" \(184 characters\)
sed "s/^X//" >'getc' <<'END_OF_FILE'
X:
Xgetc() {
X	echo "\n$* [ ]\b\b\c">&2
X	stty raw
X	reply=`dd if=/dev/tty bs=1 count=1 2>/dev/null`
X	stty -raw
X	echo "" >&2
X	echo $reply
X}
X# c=`getc "enter a character"`
X# echo "c = >$c<"
END_OF_FILE
if test 184 -ne `wc -c <'getc'`; then
    echo shar: \"'getc'\" unpacked with wrong size!
fi
chmod +x 'getc'
# end of 'getc'
fi
if test -f 'askyesno' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'askyesno'\"
else
echo shar: Extracting \"'askyesno'\" \(278 characters\)
sed "s/^X//" >'askyesno' <<'END_OF_FILE'
X:
X# $Header: $
X# @(#) $Id: $
X# $Log:	$
X#  Revision 1.1 date: 91/02/22 08:59:50
X#  branches:  1.1.1;  
X#  Initial revision
X#  
X#  Revision 1.1.1.1 date: 91/02/22 08:59:52
X#  Checkin with cvs
X#
X. getyn
Xprogname=`basename $0`
X
Xgetyn "Do you really want to run $progname" || exit 1
END_OF_FILE
if test 278 -ne `wc -c <'askyesno'`; then
    echo shar: \"'askyesno'\" unpacked with wrong size!
fi
chmod +x 'askyesno'
# end of 'askyesno'
fi
echo shar: End of shell archive.
exit 0
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
Newsgroups: biz.sco.general,comp.unix.xenix.sco
From: mknewman@blkbox (Marc Kraker Newman)
Subject: Re: X-Windows Sources for 3.2.4
Organization: The Black Box, PO Box 591822 Houston, TX 77259-1822 
Date: Sun, 20 Dec 1992 21:10:09 GMT

crouland@gmuvax2.gmu.edu (DES Cracker) writes:


>Does anyone know where I can find full blown X11 for SCO Unix 3.2.4
>running on a 386? Binaries preferred.

You could always upgrade to ODT 2.0.

Marc

-- 
Marc K. Newman (N5SLG)			Is UNIX pronounced 
mknewman@blkbox.com 			"UNIQUES" or
PO BOX 591822				"EUNICHS"?
Houston, Texas 77259-1822
From: eah@xenitec.on.ca (Ed Hew)
Newsgroups: biz.sco.general
Subject: Re: Telnet kicks me off!  Why?
Keywords: telnet, routing, latency
Date: 12 Dec 92 06:54:42 GMT
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA

In article <6057@sumax.seattleu.edu> aehall@sumax.seattleu.edu (ein Bit bitte!) writes:
>Hi!
>I have an odd problem...
>I'm configuring a SCO Unix 3.2.4 box with the latest version of TCP/IP (I
>forget the number...).  When I telnet into the machine from another host or
>an X terminal, I get in just fine, but when I do an "ls", for example, the
>contents of the directory get listed, but then I'm booted off the system
>("Connection closed by foreign host.").
>Any ideas?

It happens.

Seeing traceout stdout would help, but in general, the causes
are usually network outages (within the Internet).

Handing your packets off to the internet for routing is rather
akin to handing your baggage to a large airline.  You have no
control over exactly how they're going to get there, and typically
you really don't care, you just expect both your packets and your
luggage to arrive in a timely manner.  It's possible that some
gateway between your host and the destination host went down,
hence the remote host eventually realizes that you're gone and
closes the connection.  In any event, on your end it certainly
looks like the connection is closed, so that's what's reported
to you.  Of course, when the remote host itself goes down, it's
soon pretty obvious.

If this is a direct ethernet connection, then you want to check
your cabling and connections, and of course ensure that the
ethernet is terminated on both ends.  If that doesn't help,
verify that the ethernet cards themselves are properly seated,
properly configured, and are in good working order.  Check for
conflicts.  I'd be very tempted to suspect hardware.
--
  Ed. A. Hew,    <edhew@xenitec.on.ca>    ....!uunet.ca!xenitec!eah
  XeniTec Consulting Services, Kitchener ON, Canada +1 519 570 9848
          [biz.sco.* newsgroups and mailing lists godfather]
Newsgroups: biz.sco.general
From: apl@world.std.com (Anthony P Lawrence)
Subject: Compuserve??
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Tue, 15 Dec 1992 00:24:13 GMT

The latest issue of DiSCOver talks about a new Compuserve forum
for SCO products.

This is not a Bad Thing, in fact it's probably a Good Thing, but
for reasons I'm not entirely clear about, it makes me wince just
a little bit.

I guess it's because when all is said and done, the only reasonable
way to access Compuserve (assuming stock SCO software) is by way of
DOS!!  Yes, you can buy third party comm packages, and you could
download Pcomm, but "out of the box" SCO Unix is pretty useless at this.

This is *not* a slam at SCO!  Everybody else's Unix is probably just
as ignorant, and I'm not even sure that gratuitously (or otherwise) 
including such functionality is a necessary thing.

I guess it's just because I spend so much time convincing people that
Unix Is OK, Really! and then something like this comes up that says
"we've got all this neat Unix stuff here, but the best way to get it
is through DOS".

I dunno.  I can't say for sure why this makes me uncomfortable, but
I know it does.  I guess it could be worse: suppose you needed Windows
to run CIM!


		Tony   apl@world.std.com

Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
Xenix/Unix support,etc 	 	 Boston		 Seattle
From: MC0003@mclink.it (Bo Arnklit)
Newsgroups: biz.sco.general
Subject: Cd-Rom Problems
Date: 18 Dec 92 10:19:26 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

I'm using a 486/50MHz EISA machine with SCO 3.2.4 to run italy's leading on-line service called MC-link. I have mounted 4 cd-rom drives on the SCSI bus of a second identical machine and found that the filenames on the discs appear as "filename.ext;1". Filename and extension may be in upper and lower case and they are always followed by a semicolon and the number 1. I can access the file either using "filename.ext" or "filename.ext;1", however if I try to use the shell to expand metacharacters (like *.gif) 

it does'nt find anything, I must use "*.gif;1", but then if I use cp to copy them to a normal disk the ";1" remains attached to the filename. Filenames without extensions always have the dot attached just before the ";1", so for example "readme" becomes "readme.;1" and it is necessary that the dot is specified. I have studied the docs but there is very little about cd-roms.
Ok so I've learned to live with it, adapting my programs that interact with the cd-roms.
Yesterday I installed the cdrom drives on the production machine (identical hardware & software) but to my surprise all filenames (including directory names) are now in UPPERCASE and the ";1" suffix has disappeared.
I've spent a lot of time to "diff" the various files in /etc/conf to see if there is some flag responsible for this weird behaviuor, but I haven't found anything yet.
Anybody has any idea?
Thanks in advance, Bo.

-----------------------------------------------------------------------
Bo Arnklit - Technical Director         MC-link on-line service
e-mail: arnklit@mclink.it               Technimedia Srl
Tel: +39-6-418921                               Via Carlo Perrier 9
Fax: +39-6-4512524                              00157 ROME ITALY
-----------------------------------------------------------------------
Newsgroups: biz.sco.general
From: Bela Lubkin <belal@sco.COM>
Subject: Re: Xenix process listing
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: scogen@xenitec.ON.CA
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Sat, 19 Dec 1992 01:00:54 GMT
Precedence: bulk

Dave Van Allen wrote:

> Hopefully someone can set me in the right direction on this. In UNIX
> (SCO) If a process is swapped I can still get that processes process
> listing from in the incore copy of the process table. But in Xenix, this
> does not seem to be the case.
> 
> Seems as if xenix swaps the process list to disk too? If this is true,
> would anyone (Bela) please give me location and record layout of where
> this is stored? My program needs to be able to read the info for all
> processes in xenix, including ones swapped to disk.
> 
> I am doing it now, but what a kludge! I'd be embarrassed to even tell
> how. 

C'mon, this is cheating!  ;-}  It's not like I know anything about this,
but I *do* have the source to go figure it out.

And, having looked at the code, I think I'd be embarrassed to tell how,
too.  After figuring out the page is on swap, ps has to search for the
page in the dfmap.  The code is very messy.  If you've got it working,
I'd say, don't mess with it.  I doubt it's any messier than what ps
does.

>Bela<
Newsgroups: biz.sco.general
From: davidf@golem.waterloo.on.ca (David J. Fiander)
Subject: Re: Shell script poser
Date: Fri, 11 Dec 1992 23:28:32 GMT

According to Tim Northrup <jrsalb1!tgn@brspyr1.brs.com>:
>(mine worked first time too, so there :-)
>
>:
>while read Line ; do
>	First=`expr "${Line}" : '\(.\).*' | tr '[a-z]' '[A-Z]'`
>	Rest=`expr "${Line}" : '.\(.*\)' | tr '[A-Z]' '[a-z]'`
>	echo "${First}${Rest}"
>	done
>

You were lucky that you didn't pass it a file which had a line
beginning with one of the words 'match', 'substr', 'length', or
'index', because then you would have got

>	expr: syntax error
>	expr: syntax error
>	
>	

- David
From: brian@ilinx.wimsey.bc.ca (Brian J. Murrell)
Newsgroups: biz.sco.general
Subject: interesting mkdev hd anomoly
Date: 17 Dec 92 16:25:32 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

I had a client try add a third hard drive to his ODT 2.0 system.  He attempted
the install several times, as he changed his mind about the SCSI id half way
through the script.  The end result was very wierd.  Some more background:

	He has a Bustek ISA (adaptec commmand set) SCSI controller with 2 drives
attatched on SCSI id 0 and 1 .  He started to add the new disk with SCSI id 2,
remembered that SCO liked to put tape drives on id 2, bombed out of the
install and started up again adding the drive on id 3.  The drive worked and 
he divvy'ed it up and made filesystems.  Everything seemed hunkydory.

	I dial up his machine some time later to find some wierd configurations.

	The mscsi file had a weird entry and looked something like this
ad	Sdsk	0	0	0
ad	Sdsk	0	1	0
ad	Stp	0	2	0
??	Sdsk	0	7	3

	I can't say for sure what driver the last line had as the first field,
but I thought it wierd that there be an entry for id 7 which is the id of the
SCSI controller with a LUN of 3, so I removed it, and added one for the new
drive on id 3.

	Oooops, now the disk cannot be found by boot up, or anything.  After
some investigation in the /dev directory, I find the disk nodes (*hd2?) have
a major device number of 87.  What??  So I go to the /etc/conf/cf.d/mdevice
file to find out what device own major 87, and it's the "hd" driver.  Again,
what??  So I go back to /dev and change the major/minors of the /dev/dsk/2s?
and /dev/*hd2? to use major 1, appropriate minors for the third SCSI drive.

	Now doing post-mortem, I wonder what was going on here.  The whole 
setup works now (a relief - there's nothing like sticking your fingers into
a clients machine and having something not work when you're done!) and worked
before I dicked around with mscsi, hd devices, etc.  The one problem was the 
when the client tried to make a "CT-BOOT" disk, the program had a hemmorage
because of the third disk having a major device number of 87, and that was 
why I got called in the first place.

	Some supposition:  I dont't remember, but suspect the last entry in
the mscsi file was device hd, not ad, and that entry was somehow telling the
kernel that the hd driver referred to the device on SCSI controller with an
id of 7, and was using the LUN to denote what ID the disk was.  Merely a 
stab in the dark.

	Does anybody have any other ideas about the third disk, it's major
being 87 - owned by the hd driver, etc.

brian

-- 
Brian J. Murrell                                        brian@ilinx.wimsey.bc.ca
InterLinx Support Services, Inc.                        uunet!van-bc!ilinx!brian
North Vancouver, B.C.
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD
Newsgroups: biz.sco.general,comp.unix.programmer,comp.unix.sysv386
From: kcs@extro.ucc.su.OZ.AU (Gary Evesson)
Subject: Re: sigaction() and rescheduling interrupted system calls
Keywords: sigaction system call sco reschedule
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Wed, 16 Dec 1992 22:47:39 GMT

wes@dd.dk (Mads Westermann) writes:

>In my AT&T Sys V.4 manual there's reference to a SA_RESTART flag on
>the sigaction() function that causes interrupted system calls to be
>transparently restarted.

sigaction() did not make System V until Rel. 4. That's why it's not in a
Rel. 3 manual.

Gary Evesson
KCS Australia Pty. Ltd.
From: bob@consult.UUCP (Bob Willey CDP)
Newsgroups: biz.sco.general
Subject: Re: b.s.m proposal - discussions released f
Date: 13 Dec 92 15:50:25 GMT
Reply-To: bob@consult.UUCP (Bob Willey CDP )
Organization: CCS Enterprises, Inc. - Easton, MD

In article <9212121642.a18380@scoke.sco.COM> belal@sco.COM (Bela Lubkin) writes:
>Now that Sean has stated that he and his authors will be actively
>participating in the group, I withdraw my objections.  Their presence
>will serve to focus the group much more than I expected; the resulting
>group really will be properly differentiated from biz.sco.general.
>
>I just wish this had been mentioned earlier.
>
>>Bela<

I agree with Bela, it would have been nice to have seen this participation
interest from sean and utoday earlier in the discussion.      

Now it seems that most of the objections have now been met, and it is
probably time to get on with things.  Michael, isn't it now time for
a NEW group!!!

I think this will be a very good overall newsgroup and very beneficial
to the SCO community.

-- 
>.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  bob@ccs.com   ..<
>.. CCS Enterprises, Inc.    ..  |  ..   Office: (410) 820-4670          ..<
>.. P.O. Drawer 1690         ..  |  ..      FAX: (410) 476-5261          ..<
>.. Easton, Maryland 21601 ......|......... BBS: (410) 476-5098 ...........<
Newsgroups: biz.sco.general,biz.sco.opendesktop,comp.unix.sysv386
From: george@ve7frg.ampr.org (George Farris)
Subject: Re: HELP. Why does "talk" say "machine to confused"
Organization: G.M. Systems
Date: Fri, 18 Dec 1992 16:55:58 GMT
X-Newsreader: TIN [version 1.1 PL6]

Syd Weinstein (syd@dsi.com) wrote:
: george@ve7frg.ampr.org (George Farris) writes:
: >When a user is logged in over the network from a machine via telnet and
: >I try to "talk" to that user via "talk username".  Talk responds with:
: >[Target machine is to confused to talk to us].  This is under ODT 1.1,
: >update G.  I can use "write" to talk to the user but not talk.  Can any
: >one help with this it's driving me crazy :-)
: 
: The message is a bit weird, but I'll bet the problem is one of byte
: ordering.  Talk, a rather old protocol, was designed when all the
: machines used the same byte order.  Thus it is byte order dependent.
: 
: Thus if the machine you are trying to talk to is a Sun, or that ilk,
: that uses an opposite byte order from your x86, it won't work.
: 

I guess I didn't make myself clear with this question.  I'm not trying
to "talk" to another machine.  The talk process is going between me
logged in on the console and "user" logged in to the  * same * machine
via a telnet connection.  The talk process would then be trying to work
between tty01 and ttyp00.  In fact just trying to talk to another login
on tty02 or tty1a which is a terminal connected by a serial link gives
the same message.  Very strange.  It almost seems as if talk and talkd
don't like each other and in fact I would suspect the byte ordering
problem if these two were not supplied as part of ODT. Hmmmm....
something in the back of my mind tells me that they did used to work at
one time.

-- 

==========================================================================
George Farris - VE7FRG          Internet  :  george@ve7frg.ampr.org
                                 Amprnet  :  george@ve7frg.ampr.org
From: jpr@jpradley.jpr.com (Jean-Pierre Radley)
Newsgroups: biz.sco.general
Subject: Re: Compuserve??
Date: 20 Dec 92 06:53:14 GMT
Reply-To: jpr@jpr.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Content-Length: 580
Precedence: bulk

Steven W Orr writes:
> 
> Could someone point me to the source code for XC? I just archied the
> planet and got bupka.

I have XC ready to ship either with or without protoypes. Tell me which one
you want. You get five shar files of just under 50K each.

I uploaded the non-prototype code to CompuServe half a year ago, in UnixForum,
Section 4.

FTP, (with function prototypes):

	ftp.eunet.ch (146.228.10.15)

	the seperate shar files and a compressed tar file of xc
	are in

	software/comm/xc

-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
Newsgroups: biz.sco.general,comp.unix.sysv386,comp.unix.pc-clone.32bit