HDTenEightyP/NetNews huggingface dataset:
From: petri@cerebus.inter.fi (Petri Wessman)
Newsgroups: biz.sco.general
Subject: Re: [SCO] execvp(2) seems to fail on shell scripts!
Date: 12 Jan 93 08:38:53 GMT
	<m0nBVcg-000FkkC@ilinx.wimsey.bc.ca>
Reply-To: Petri.Wessman@hut.fi
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

On Mon, 11 Jan 1993 12:20:34 -0800 (PST), Brian J. Murrell <brian@ilinx.wimsey.com> said:

> The program basicly does a fork + exec for each program it is
> monitoring, and blocks in wait(). If a child dies, it is restarted.
> The programs that it starts are /bin/sh scripts, and this seems to be
> the root of the problem. Things work fine for a while, but after an
> unknown interval of time (usually the next day), *something* goes
> wrong. After this point, it can't seem to start a single one of the
> programs. Exec() works fine (doesn't return error), but the script is
> never executed (we've tested N+1 variations) and wait() gets an
> "exited with status 0" for the child that was "started".

Brian> oh, boy does this sound familiar.  The worst part is that as
Brian> far as the program is concerned the script gets executed!!
Brian> This sounds _very_ familiar!!

Brian> do you try to run as a daemon (i.e. disassociate from the terminal)?

Yup. The program does a freopen for fds 0,1 & 2, does a setpgrp(), and
forks itself into the background.


Brian> the thing I noticed is that when I was logged in on the terminal that
Brian> started the program all would be fine, as soon as the user which started
Brian> the program logged out of their terminal, the fishy behaviour started 
Brian> again!!

Hmm...

Brian> the only way I could fix it, don't log out of the terminal which the 
Brian> program is on.

Argh. No can do. I'll have to dig up our tattered copy of Stevens'
Unix Network Programming and check that we're doing the backgrounding
right. Not that it should matter to exec() succeeding, but I'm firmly
beginning to suspect Gremlins on this one :-)

If anyone from SCO is reading this: hasn't anyone reported problems
like this before? I know that probably not many people have programs
running as daemons that start up shell scripts on a continual basis,
but still...

//Petri
Newsgroups: biz.sco.general
From: John Perry <jep@ohriman.mi.org>
Subject: Re: compiling GNU programs
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Reply-To: jep@ohriman.mi.org
Organization: Arbornet, Inc. (M-Net Public Access Unix: 313-996-4644)
Date: Wed, 6 Jan 1993 23:06:08 GMT
Content-Length: 1756      
Precedence: bulk

> |> 	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):
> 
> 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...

	Thanks!  Mike Trim also saw my plea and suggested I try GNU make.
That also got me past the 'end of file unexpected' error.  Like you,
my compilation eventually got stuck in CursesW.  Has anyone else had
this problem and resolved it?

	Also, if you omit CursesW to go on, can you then compile groff
1.06 without difficulty, or is that going to open another can of worms?
(I suppose I can just try it and see...)

	The advice from Hank van Cleef about using -traditional,
-DNO_PROTOTYPES, -Di386 and -U__STDC__ has also helped a lot with
compiling GNU software on SCO 3.2v4; I now have working copies of all
the textutils 1.3, shellutils 1.8 and fileutils 3.4 programs except
for su.  Some programs are still eluding me, including oleo 1.2 and
texinfo 2.16, but a lot of stuff is working now that I couldn't get to
work before.

-- 
John Perry      jep@ohriman.mi.org      ..!destroyer!netmeg!ohriman!jep
From: paul@openage.COM (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: 36 pin parallel port available????
Date: 13 Jan 93 02:19:38 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Hi All,

A customer of mine is getting ready to cut over from a Plexus P/60 to their SCO 
box.  They have an old high speed line printer that seems to need much less in 
the way of repairs than my car, and the printer is older!  My question is how 
to connect the 36-pin cable on the printer to a PC?  I can't change the cable, 
because it is integral to the printer.  I either need a black box to convert a 
25-pin parallel to 36-pin, or a PC board with a 36-pin connector.

Any help on this would be appreciated.

--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
From: pc3270@oliveb.ATC.Olivetti.Com (Marco Aquilano)
Newsgroups: biz.sco.general
Subject: Remove
Date: 12 Jan 93 10:58:36 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Return-Path: <pc3270@xsft2>
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

remove pc3270@xsft2.ico.olivetti.com
From: frankb@eplegal.UUCP (Frank Brock)
Newsgroups: biz.sco.general
Subject: MERGE w/ smart board com ports fails??
Keywords: merge,com ports
Date: 11 Jan 93 03:14:43 GMT
Organization: Eagle-Picher Inc.


We are using Merge 2.2.0 on Unix 3.4.1/MPX2.0 and are unable to connect 
a com port to a serial port on a Digiboard C/CON 16 (Driver 
V4.7.2), we also cannot connect it to the SIO/386 (corollary 
sio/cpu board in ALR3000).  We have the same trouble on an ALR 
VEISA with Unix 3.4.0.

dos +acom1=/dev/ttya11 

yields

INITDEV_FAIL: dos: ERROR: Could not initialize '/dev/vcom1=/dev/ttya11'.

The permissions on the tty are 666

The same command works fine on the real com port.

has anyone had any experience in this area?  any advice.

frank brock
frankb@eapi.com

Newsgroups: biz.sco.general
From: news@pwh.uucp (news administrator)
Subject: sco unix 3.2.4 and sco unix development 3.2.4 updating
Organization: PWH Associates
Date: Sat, 09 Jan 93 19:23:42 GMT
Keywords: development system, sco

I tried to install the update for the sco development system
under sco unix 3.2.4. everything went well until the last custom
screen. it asked for product [null]
disk M1
i assumed it ment m1 for unix which i supplied.
it told me incorrect release. i tried m1 from 3.2.2
since i had to use the serial number and activation key from
that version. it rejected that also.
i called sco, but they haven't bothered to call back.
i escaped out of custom, not completing the installation.
anyone have any ideas why i got the error?
i tried to compiling a simple program which went fine.
will I have problems in the future?
thanks.
phil

Newsgroups: biz.sco.general
From: gerg@netcom.com (Greg Andrews)
Subject: Re: UUCP woes on 3.2.0 to 3.2.4 upgrade
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Distribution: biz
Date: Mon, 4 Jan 1993 08:49:51 GMT

vancleef@netcom.com (Henry van Cleef) writes:
>
>As it says, I upgraded my machine from 3.2.0 to 3.2.4 last week, and now
>uucp and cu won't play.  I've looked at all the obvious things:
>
>1. permissions correct on /dev/tty1A, port set off in inittab.
>2. Devices and Systems entries were copied from the old installation.
>3. Configuration is Tbit 1000.  I have tried using the old dialTBIT
>binary in case the new one was different.
>
>Symptom:  Dial and connect work OK, and I get the login: response.
>But when I try to send (either uucico OR cu) characters don't echo
>(cu) and uucico never sees sword: or Shere=sysname (uutry -x9).
>The returns on cu echo one letter per cariage return and evidently are
>sent that way.  
>

No, they're received that way.

The problem happens because changes were made in the tty driver between
v2.0 and v4.0, but the dialTBIT source wasn't adjusted to match.

This is the problem in a nutshell:

A change was made in the stock tty driver concerning the RTSFLOW
line discipline, and the dialTBIT source code was not changed to
match.

Solution that's worked for me:

Change dialTBIT.c to set CRTSFL instead of RTSFLOW and CTSFLOW, and
recompile.  The change is made to mdopen() at or near line 1520.

Old line:

	term.c_flag |= (CLOCAL | CTSFLOW | RTSFLOW)

New line:

	term.c_flag |= (CLOCAL | CRTSFL)

If you're paranoid enough, you could even include a line that clears
RTSFLOW and CTSFLOW, but it's probably not necessary.

If you want a more detailed explanation of why RTSFLOW doesn't work anymore,
let me know.  I just didn't want to bore everyone with technicalities if
they aren't wanted...  (Hint: Attach a breakout box and watch the RTS
signal from the computer, then look up the meaning of S58=2 in your T1000
manual).

  -Greg
(Telebit Engineer)
-- 
:::::::::::::::::::  Greg Andrews  gerg@netcom.com  :::::::::::::::::::
ObGuindon:  Roger Blunt has been saving newspapers most of his life.
            Later on, he figures to make some trees.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
From: kumar@cleaver.mti.sgi.com (Kumar Venkat)
Newsgroups: biz.sco.general
Subject: Question on using Maxtor SCSI hard drive
Keywords: hard drive, disk drive, SCSI, Maxtor
Date: 11 Jan 93 19:50:34 GMT
Organization: Silicon Graphics, Inc.


I have a question for anyone who has used a Maxtor
LXT 535S SCSI hard disk drive, with SCO Unix.

If I use auto-intialization of the hard drive while
installing SCO Unix 3.2v4.0, it picks the following
parameters:

	number of cylinders = 510
	number of heads = 64
	number of sectors/track = 32
	block (sector) size = 512 bytes

Multiplying these out does produce 535 MB.

HOWEVER, I only find about 1/3 of the disk space
that I expect (using 'df').  'fdisk' indicates that
the disk size is 32640 tracks.

Looking at the Maxtor installation notes, I find that the 
number of cylinders for a "535SY" (535S not listed) is 1560.

I can see that I need to set the disk parameters differently.
But I can't reliably find the top three parameters above for
the LXT 535S. Maxtor's technical support seems limited.

(I do have a DOS partition in the first 40 MB, and 'fdisk' 
under DOS does indicate 510 MB of total disk size.)

So, I would *really* appreciate any help or pointers on
configuring this hard drive for SCO Unix. 

Thanks,

Kumar Venkat

kumar@mti.sgi.com
(415) 390-4428
Fax: (415) 390-6176
From: larryp@sco.COM (Larry Philps)
Subject: Re: Imake & sco.cf
Organization: SCO Canada, Inc.
Date: Mon, 04 Jan 1993 15:18:23 GMT

In <9212261810.AA29472@jpradley.jpr.com> Jean-Pierre Radley <jpr@jpradley.jpr.com> writes:

>  ODT 2.0
>  
> I'm getting tired of editing Makefiles by hand.
> 
> Has anyone fixed up /usr/lib/X11/configure/sco.cf to have imake
> produce Makefiles that would use the shared C and the shared X libraries?

(The directory is actually /usr/lib/X11/config).  Just edit sco.cf to
add the line

	define UseSharedLibraries    YES

and also add "-lc_s" to the end of the "ExtraLibraries" define.
Xmkmf should then use the shared motif, X11 and C libraries.

> /shlib:
> -rwxr-xr-x   1 bin      bin       304438 May 07  1992 libXR4sco_s
> -rwxr-xr-x   1 bin      bin      1213844 May 07  1992 libXtXm114_s
> -rwxr-xr-x   1 bin      bin      1032412 May 07  1992 libXtXm_s

I am not 100% sure, but I think it is the X11R3 version of the Xt and
Xm shared library.

---
#include <std/disclaimer>

Larry Philps,	 SCO Canada, Inc.
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM
UUCP:	  uunet!sco!larryp
Phone:	  (416) 922-1937
From: paul@openage.COM (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: RE: MERGE w/ smart board com ports fails??
Keywords: merge,com ports
Date: 11 Jan 93 20:45:44 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>We are using Merge 2.2.0 on Unix 3.4.1/MPX2.0 and are unable to connect 
>a com port to a serial port on a Digiboard C/CON 16 (Driver 
>V4.7.2), we also cannot connect it to the SIO/386 (corollary 
>sio/cpu board in ALR3000).  We have the same trouble on an ALR 
>VEISA with Unix 3.4.0.

>dos +acom1=/dev/ttya11 

>yields

>INITDEV_FAIL: dos: ERROR: Could not initialize '/dev/vcom1=/dev/ttya11'.

>The permissions on the tty are 666

>The same command works fine on the real com port.

>has anyone had any experience in this area?  any advice.

The multiport vendor must build Merge support into their driver.  In earlier 
versions of Merge there was no device driver writers guide to Merge, because 
Locus didn't have one!  SCO has since put one out, but no multiport 
manufacturer has seen fit (as far as I know) to release a Merge ready SCO 
driver for their product.

Until the driver is their you can only "+acom1=/dev/tty[1-2]a".  Sorry.

Go yell at Digiboard, maybe they'll change.

--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
Newsgroups: biz.sco.general
From: paul@sco.COM (Paul Jackson)
Subject: Re: Three compilers compared on Unix 3.2v4 (long)
Organization: SCO Canada, Inc.
Distribution: biz
Date: Mon, 04 Jan 1993 19:05:19 GMT

In article <1i9521INN5o7@mailgzrz.TU-Berlin.DE> gb@buran.fb10.tu-berlin.de (Guenter Becker) writes:
>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 ?

Current plans are to have the alloca routine available in the Maintenance
Supplement for the SCO Development System. I'm not sure what the expected
availability date for this is.
Newsgroups: biz.sco.general
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: Is BBx Progression 3/4 supported on SCO NFS?
Organization: Celestial Software, Mercer Island, WA
Date: Tue, 12 Jan 1993 16:53:00 GMT

In <36@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes:

:In article <2817@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes:
:>I have installed NFS on two systems, both running BBx Progression
:>accounting applications.  Users on each system need to access the
:>other system's BBx application, so each system's home BBx
:>directory (containing programs and data subdirectories) is NFS
:>mounted on the other system.
:>
:>When a user on system A opens a file using BBx and a user on
:>system B tries to open the same file (located in an NFS mounted
:>directory on system B), an error code 0 is received (file
:>busy/locked).  This particular file in never really locked in a
:>local application, simply a record is extracted for reading.
:>
:>In a local environment, dozens of users could read this file
:>simultaneously.  In an NFS environment, having one remote user
:>reading the file makes it locked for a local user.  It was
:>suggested to check with J.P.  Brown (Canadian distributors for
:>Basis of BBx) to see if the product even runs in an NFS
:>environment.  I will be doing this on Monday, but thought I would
:>see if anyone has had any experience with this.

:Sure, I have a bit of experience with this.  File locking under NFS
:has always had a history of trouble, but I suspect that the issue that
:you're having is a bit different.

:BBx4 (due to historical constraints) notifies other processes that it
:has a particular file open by locking a small piece of the file.  On
:versions of BBx prior to BBx4 this piece was selected by starting at a
:high (and nonexistent) address and attempting locks until one worked. 
:On BBx4 the lock bit is allocated at the time the process is started.
:This works well on a local filesystem, but on a remote can fail.
....stuff deleted....

All these are excellent arguments against running transaction
processing applications over a network!  It would seem to me that
the best solution is to rlogin/telnet into the system that has
the accounting system on it and run on that system.  We do this
with our Unify based accounting applications and all locking is
handled in shared memory on one system.  This is orders of
magnitude faster than trying to handle locking over a network and
bypasses all problems with NFS locking.

Bill
-- 
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
From: chapman@sco.COM (Brian Chapman)
Subject: Re: Performance degradation under SCO UNIX
Organization: The Santa Cruz Operation, Inc.
Date: Tue, 5 Jan 1993 02:01:46 GMT

geoff@zswamp.UUCP (Geoffrey Welsh) writes:

>mike@pacsoft.com (Mike Stefanik) writes:

>> This posting is on behalf of a friend of mine who is having a problem
>> with an SCO UNIX upgrade.  A customer of his originally had a 486/33
>> with 16M of memory and a 1G SCSI drive.  Recently, the system was upgraded
>> to a 486/50 with 32M of memory and an additional 1G drive was added
>> [...]
>> Unfortunately, the system is now crawling along at a snail's pace.

>   Make sure that there's 64KB static cache RAM for each bank of 16MB dynamic 
>RAM.  Make sure that the BIOS setup is configured to cache all installed 
>dynamic RAM.

Yes this is a common source of grief.  I have worked with a couple of
customers who found a 2.5 Times (!) performance loss (using C compiles
as a benchmark) when they up graded from 16 to 32 Meg of memory in
486 machines.  This was traced to not enough cache in the secondary
cache.  (credit goes to bela, and the net, for the idea to check
this out).

Unfortunatly if you don't have enough external cache the high memory
address are not cachable by the external cache and that prevents even
the 486 internal cache from caching it.  (This has to do, I think,
with "The principle of inclusion" -- Every address cached in the primary
cache is also in the secondary cache).  The exact mapping of how much
cache will cover how much memory differs among vendors but normally
64K cache covers 16Meg or multiply your cache size by 2^8.  I have
seen machines where the figure was 2^7 and 2^9.  A big part of the
performance difference between a 386 and a 486 is the caching, you
don't want to mess it up!

The problem (for SCO) is most people see this performance loss when
they upgrade from 32v2 to 32v4, because v4 loads the kernel into
highest possible memory to preserve the maximum amount to <16M
DMA'able RAM.   My measurments showed a 4 to 1 difference in access
time, and if you kernel is up there you system is going to show it.

My advice is boot with "mem=/L"  (load the kernel in the low 16 Meg)
until you can get your cache upgraded.
	-- Chapman
Newsgroups: biz.sco.general,comp.unix.sysv386
From: jackl@pribal (jack lowry)
Subject: 9 track (1/2") tape drive suggestions for SCO unix
Organization: Prism Medical Systems
Date: Thu, 07 Jan 1993 01:42:45 GMT


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
NovaStor Corp
Qualstar
Overland Data.
CONTECH

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. 

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?

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
From: infmx!ten_forward!aland@uunet.UU.NET (Alan Denney)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 4 Jan 93 18:52:11 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: ten_forward!aland@uunet.UU.NET
Precedence: bulk

Re: how to get SCSICNTL

Roy Neese sent me the new number for adaptex (his UNIX box, on which he keeps
SCSICNTL available for uucp access).  Here's the uucp info repeated, with the
correct phone number this time.  (This may have also been posted to the
group, but our newsfeeds appear to be down.)  The current version of SCSICNTL
is 6.4I.

-------------------------------------------------------------------------------
adaptex uses a Telebit T1000.  So 9600 baud connections can only be made
using PEP.

Put the following line in your /usr/lib/uucp/Systems file.

adaptex Any ACU BAUD 18173294520 -\d\d\d-gin:-BREAK\d\d\d-gin:-BREAK\d\d\d-gin: suucp

NOTE: The word BAUD can be replaced with either 9600, 2400, or 1200.

You can snarf the following compressed binary files via uucp.

1540CPU.LIST.Z  GRDRIVE.EXE.Z   SCSICNTL.EXE.Z  1540DRV.LIST.Z  GREAD.EXE.Z
SCSIHA.SYS.Z    1540USR.MAN.Z   GWRITE.EXE.Z    SETSCSI.EXE.Z   sco.patches.Z
sds3.desc.Z     LIST            setscsi.doc.Z   @0F1F.ADF.Z     README
inq.Z           scsicntl.doc.Z  GETDEVS.EXE.Z   SCSI.EXE.Z      list

Use the following command:

uucp adaptex!~/filename /usr/spool/uucppublic/filename

--
uucp adaptex\!~/scsicntl.doc.Z /var/spool/uucppublic/scsicntl.doc.Z
uucp adaptex\!~/SCSICNTL.EXE.Z /var/spool/uucppublic/SCSICNTL.EXE.Z

--
Replace 'filename' with the appropriate name of the file that you want.  To
those who only want the mode sense fiddler, it is the SCSICNTL.EXE.Z file.
-------------------------------------------------------------------------------

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland

    Never trust a UNIX programmer who can't spell "kernel".
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 7 Jan 93 21:01:44 GMT
Organization: Izot's Swamp

kevin@shady.UUCP (Kevin Smith) writes:

> Can anyone clearly state what exactly the DMA transfer speed on the
> 1542B actually specifies?  Computer memory to card?

   Yes.
> If so, isn't this
> somehow constrained by your bus speed or controlled by the DMA on
> the motherboard...???

   I would think that the bus speed affects it, but I'm not sure exactly how.  
Some assumptions must have been made.

   The whole point of the 1542 is that its DMA bypasses the motherboard's 
normal DMA process (i.e. it reads/writes memory directly, rather than letting 
the DMA controller read from memory and then write to the device or vice 
versa).

> One of the other postings implied is was the
> data transfer rate on the SCSI bus while another implied it had to do
> with the computer/adaptor interface?

   I believe that the posting in question was in error.

  Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
                Now I've lost everything, I give to you my soul
           And the meaning of all that I believed before escapes me
                  In this world of none, no thing, and no one
                            - Genesis, _Afterglow_
Newsgroups: biz.sco.general