HDTenEightyP/NetNews huggingface dataset:
From: airon@edm.isac.ca (Airon Yan Sung Yiu)
Subject: TN327 Emulator using Pathworks for DOS TCP/IP socket library
Organization: ISA Corporation, Edmonton, AB
Date: Wed, 26 Aug 92 17:25:59 GMT
Followup-To: Poster
Summary: Problems with Pathwork for DOS TCP/IP socket read
Keywords: Pathworks , TN 3270

Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Tn3270 Emulator using Pathwork socket library
Summary: Problems with Pathwork (DOS) socket read
Followup-To: poster 
Distribution: world
Organization: ISA Corporation, Edmonton, AB
Keywords: 


--------------------------------------------------------------------
I have the same problem when using Pathworks for DOS TCP/IP version 2.0.
I have included the first mail that I sent out for your reference.
--------------------------------------------------------------------
*** Previous mail ***

Hi, folks :
I have modified the NCSA Telnet/TN3270 emulation program to work with
Beame and Whiteside TCP/IP socket library and everything works fine.
However, I encountered some problems when I tried to port the program to
work with DEC Pathworks socket library.  It seems that the socket read
function in the Pathworks socket library does not clear the internal
storage buffer before each call (by the way, I clear my own storage
buffer before socket read is called each time).  Consequently, each time
the program reads new information from the network, there is some
leftover stuff from previous socket read calls.  This causes the Telnet
negotiaiton for 3270 sessions to fail.  I had similar problems when I
used the same 3270/Pathwork program (running in VT100 mode) to connect
to our Sun 4.

Can anyone help me ?  Here are some details about the program :
  Pathworks for DOS version 4.1
  Pathworks for DOS (TCP/IP) version 1.1A
  The NCSA/3270 program was ported from Turbo C (v 2) to MicrSoft C (v 6)

Please reply to my e-mail address and I will post the summary of
response.  Thank you.

-- 
Airon Y.S. Yiu 		         mail: airon@edm.isac.ca
ISA Corp.			 uucp: !{uunet, alberta}!isagate!airon
Edmonton, Alberta, Canada       phone: (403) 420-8081 
Newsgroups: comp.protocols.tcp-ip
From: oak@odda.er.sintef.no (Olav Kvittem)
Subject: How "reliable" is UDP
Organization: SINTEF, Trondheim, Norway.
Date: Wed, 2 Sep 92 20:45:56 GMT

Hello,

I have run some ttcp tests sending UDP-datagrams to test a 34Mbps/FDDI/Ethernet
network.

If I run the test on a Sun :

packetsize	KB/sek		CPU usage	Mbps    Interface
8000		2437		96%		20.0  	Ether
4000		2051		98%		16.4  	Ether
1400		1166		98%		 9.3  	Ether
1000		 941		97%		 7.5	Ether

From this I deduce that many packets does not leave the machine before they are
dropped. Even with an FDDI interface very few of the packets make it out of the
machine at 8192 packetsize (size of data for socket write operation). 

If I do the same tests on a DECStation Ultrix system it seems to be more "reliable" :

Ethernet :
8192		1051		30%		 8.0	Ethernet
8192		3033		92%		24.2    FDDI 

We see that the CPU usage is low keeping the Ethernet UDP at near maximum
Ethernet speed.  That might indicate that the DECsystem have a blocked
write for UDP sockets while the Sun kernel accepts UDP packets at full speed and
drops them if buffers fill up ? Perhaps there are no buffers in a UDP-implemntation ?

Does anyone have any explanation or observations for this behaviour ?

Regards
  Olav
 
FDDI :
-- 
   Olav Kvittem : SINTEF

      RFC Address     Olav.Kvittem@delab.sintef.no
      OR Address      C=no;ADMD=" ";PRMD=uninett;
                      O=sintef;OU=delab;S=Kvittem;G=Olav
      Postal Address  SINTEF DELAB
                      N-7034 Trondheim
      Phone           +47-7-532586(FAX)
      Phone           +47-7-596981
      Description     Research Scientist  -  Communication Networks

Newsgroups: comp.protocols.tcp-ip
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: SLIP
Organization: The Gator Public Access Unix Site - 219-289-3745
Date: Mon, 24 Aug 1992 01:07:57 GMT

susan@moo.org (Susan Dean) writes:


>Does anyone know if there is SLIP for System V/386 avaliable via FTP?

SLIP comes with most SVR3.2 and SVR4 releases -- heck, ISC and Dell
have been shipping SLIP for a couple of years..  Who's UNIX are you
running?

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP RFC and multi-line replies?
Date: 3 Sep 1992 04:33:13 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <peter-020992112136@134.7.50.3> peter@cujo.curtin.edu.au (Peter N Lewis) writes:
>         If
>         an intermediary line begins with a 3-digit number, the Server
>         must pad the front  to avoid confusion.
>
>In particular the last sentence, would indicate that the above format is in
>fact illegal

I think that sentence was misworded.  It should have said, "If an
intermediary line begins with a 3-digit number followed by space, ...."
There's clearly no reason why a client should be confused by intermediary
lines prefixed with "123-".

>But thats neither here nor there.  I'm wondering if there is any
>disagreement on this point, is the first format actually valid?

Certainly.  The rule is that the first line must begin with "123-", the
last line must begin with "123<space>", and the intermediary lines must not
begin with "123<space>".  The above sentence was intended to easy
interoperability with clients that look for any
<digit><digit><digit><space> prefix rather than trying to match the
original ("Be conservative in what you send").

I've seen some FTP servers whose greeting messages contain:

230-If your ftp client has problems with the extended messages (or if you
230-simply find such messages annoying), connect again and use a password 
230-that begins with "-" to disable these messages.

So I suppose there are some clients out there that can't handle multiline
replies.  However, they may have trouble with them in any format.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.protocols.tcp-ip:4303 comp.protocols.tcp-ip.ibmpc:5059 comp.dcom.lans:1922
From: Jerrod@Lilly.Com (Jerrod T. Carter)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject: Re: TCP/IP programming reference material wanted
Date: 4 Sep 92 15:49:47 GMT
Distribution: world,local
Organization: Eli Lilly & Company



James 'J' Allard, jallard@microsoft.com writes:
>Finally, if you're thinking about doing some Windows programming over
TCP/IP,
>it's probably worth your time to check out the recently released Windows 
>Sockets specification available on ftp.uu.net under the
/vendors/microsoft
>directory. The specification was jointly developed and endorsed by about

Is this spec available at some other FTP site? I am unable to get
connected to
either of the addresses that the name server shows.
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.os2.misc,comp.os.os2.networking
From: eclarke@ibmpa.awdpa.ibm.com (Eric S. Clarke)
Subject: Re: Need help with getting IBM's TCP/IP running under OS/2
Organization: IBM Advanced Workstations Division, Palo Alto
Distribution: na
Date: Wed, 2 Sep 92 21:13:53 GMT

In article <Btp7wu.2Bv@fmsrl7.srl.ford.com>, probert@fires1.uucp (Neal W. Probert) writes:
|> I just installed the 3COM 3c505 driver for OS/2 2.0 for use with IBM`s
|> TCP/IP package.  Here's what I get from STARTUP.CMD:
|> 
|> CALL C:\TCPIP\BIN\TCPSTART.CMD
|> CONFIGURING TCP/IP
|> add net default: router 128.5.192.3: (null): Network is unreachable
.
.
.
|> -- 
|>     FORD       | Neal W. Probert   E3154 SRL    | probert@fires1.srl.ford.com
|>  SCIENTIFIC    | Ford Scientific Research Labs  | 313-845-8178 FAX 313-337-5581
|> RESEARCH LABS  | Dearborn, MI 48121-2053        |

Have you installed the latest CSD for the TCP/IP package? 

The base TCP/IP should show version number 1.20.1 and CSD level of UB02231
when you do a syslevel.  The LAPs package should show version number 2.01
and a CSD level of WR06000

-- 

Eric S. Clarke                     INTERNET:  eclarke@ibmpa.awdpa.ibm.com 
1055 Joaquin Road                      UUCP:  uunet!ibmsupt!eclarke
Moutain View, CA 94043             IBM VNET:  ECLARKE at AUSTIN
415-694-3858  T/L: 466-3858
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Broadcasting and Subnets
Date: 3 Sep 1992 22:52:53 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world,local
NNTP-Posting-Host: telecaster.think.com

In article <1992Sep3.090735.3657@arizona.edu> Leonard@Arizona.EDU writes:
>The best and easiest approach is just to use ALL 1's (255.255.255.255) as your
>broadcast address.  That way you don't have to worry about your subnet mask,
>or for that matter even what your own IP address is.  Recommended by 
>RFC-1122, sec. 3.3.6 (discussion section.)

One issue that's not raised in that section is the situation when multiple
IP subnets are on the same link.  The choice between limited broadcasts and
subnet broadcasts affects which group of machines will receive the
broadcasts, and may affect the behavior of the protocols you use.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP/IP break - terminal server?
Date: 2 Sep 1992 23:17:16 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

The TELNET protocol includes a Break command, which is IAC BRK (255 243);
see p.12&14 of RFC 854.  Whether the Xyplex terminal server actually
translates this to an RS-232 break I don't know.  Also, if xyp_ptyd is
trying to provide a transparent pathway, it might double the IAC.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: TSRs ...
Date: 4 Sep 1992 07:32:51 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

Quoth tto@aspentec.com (in <1992Sep3.121205.863@aspentec.com>):
#In article <Btyu2v.AG3@watserv1.uwaterloo.ca>, 
#eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
#> tto@aspentec.com writes:
#
#>>Another nice thing about FTP's PC/TCP package is that it allows an easy
#>>access to the global file descriptors.  With other packages one has
#>>to do more work in order to share a descriptor among several applications.
#>>(By the way, sharing file descriptors is one of the few things that can
#>>be done more easily on DOS than on Unix.)
#> 
#> Yes, most of the others require you to change your PSP back to the 
#> originator's.  That's easy enough when they provide source, but the 
#> one's that don't are a true headache because you have to reverse engineer 
#> or run through hoola hoops just to do shared access.  

In the case of PC-NFS, the reason you have to switch to the owner's
PSP is because our socket handles are real file descriptors - you can
read and write them using DOS calls. (When you referred earlier to
FTP's "global file descriptors" you should have called them "private
non-file socket descriptors".) Now you can argue whether or not having
sockets be "real files" is more useful than having the freedom to
manipulate descriptors at will - it certainly takes a lot of extra
work on our part - but we found that we had a lot of Unix stuff
to port which assumed that sockets were streams... And if sockets
are (DOS) files, then you can't get around the need to switch PSP's.

Geoff

--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
-----------
News software that enforces a four-line .signature limit is responsible for
the fact that these postings just go on and on and on and seem to end in mid-
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs
From: ian@unipalm.co.uk (Ian Phillipps)
Subject: Re: How to mount PC file systems via tcp/ip? 
Keywords: mount PCNFSD
Organization: Unipalm Ltd., 216 Cambridge Science Park, Cambridge CB4 4WA, UK
Date: Sun, 30 Aug 1992 23:24:09 GMT

jbvb@vax.ftp.com  (James B. VanBokkelen) writes:

>In an effort not do do "the Emperor's New Clothes" with "NFS Security",
>the IDMNT.EXE we distribute insists on authentication via a PCNFSD server,
>and doesn't allow the user to specify the UID/GID as integers.  Thus, it
>can't talk to SOSS.  However, you can get from our Tech Support people
>a MNT.EXE which lets you specify UID/GID and mount SOSS (and other things
>that don't have PCNFSDs available).

>James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
>FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

... and, a little safer, the 2.1 version of IDMNT will allow you mount
drives but have the authenitcation come from a single machine.

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
	The road to hell is paved with melting snowballs - Larry Wall
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: NetWare and Packet Drivers 
Distribution: world
Date: Wed, 26 Aug 92 14:43:15 GMT
Organization: Crynwr Software

In article <2.5000.30.2a98116f@gate.dialnet.msk.su> maximn@gate.dialnet.msk.su writes:

           I need to find out packet and/or .NLM drivers for D-Link DN-100 cards.
   Maybe anyone can help me and tell me where can I get them or buy or excange?

DN-100?  I don't recognize that number.  I'd try asking D-Link --
they supply their own Crynwr-derived packet drivers.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX
From: glenn@bass.aic.co.jp (Glenn Mansfield)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: X on PC over a serial link - is it possible ?
Date: 28 Aug 92 01:55:05 GMT
Distribution: comp
Organization: Advanced Intelligent Communication System Lab., Sendai, Japan.

Hi !

The subject line says it all. Is it possible to run X on a PC over
a serial link - using pds or non-pds ? Has anyone already tried it?

glenn
From: ddl@burrhus.harvard.edu (Dan Lanciani)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Unloadable ODIPKT?
Date: 29 Aug 92 18:51:18 GMT
Article-I.D.: burrhus.1992Aug29.185118.3511
Organization: Harvard University, Cambridge, MA

In article <david.hoisve.49.715061764@uuserv.cc.utah.edu>, david.hoisve@uuserv.cc.utah.edu writes:
| Has anyone developed an unloadable version of ODIPKT?

	Yes, the original :)

| I've tried termin, along with marknet and relnet, with limited success.  A 
| version of ODIPKT that would unload would be very useful.

	termin will work, marknet/relnet won't.  What is your symptom
of failure?

				Dan
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: airon@edm.isac.ca (Airon Yan Sung Yiu)
Subject: TN3270 Emulator using Pathwork for DOS TCP/IP socket library
Organization: ISA Corporation, Edmonton, AB
Date: Wed, 26 Aug 92 17:35:44 GMT
Followup-To: poster
Summary: Problems with Pathwork socket read 


--------------------------------------------------------------------
I have the same problem when using Pathworks for DOS TCP/IP version 2.0.
I have included the first mail that I sent out for your reference.
--------------------------------------------------------------------
*** Previous mail ***

Hi, folks :
I have modified the NCSA Telnet/TN3270 emulation program to work with
Beame and Whiteside TCP/IP socket library and everything works fine.
However, I encountered some problems when I tried to port the program to
work with DEC Pathworks socket library.  It seems that the socket read
function in the Pathworks socket library does not clear the internal
storage buffer before each call (by the way, I clear my own storage
buffer before socket read is called each time).  Consequently, each time
the program reads new information from the network, there is some
leftover stuff from previous socket read calls.  This causes the Telnet
negotiaiton for 3270 sessions to fail.  I had similar problems when I
used the same 3270/Pathwork program (running in VT100 mode) to connect
to our Sun 4.

Can anyone help me ?  Here are some details about the program :
  Pathworks for DOS version 4.1
  Pathworks for DOS (TCP/IP) version 1.1A
  The NCSA/3270 program was ported from Turbo C (v 2) to MicrSoft C (v 6)

Please reply to my e-mail address and I will post the summary of
response.  Thank you.

-- 
Airon Y.S. Yiu 		         mail: airon@edm.isac.ca
ISA Corp.			 uucp: !{uunet, alberta}!isagate!airon
Edmonton, Alberta, Canada       phone: (403) 420-8081
From: kb@jet.uk (Kenneth Blackler)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Terminal Emulation for PC
Summary: Terminal Emulation Software for PC
Date: 3 Sep 92 16:48:39 GMT
Organization: Joint European Torus


Hello,

Can anyone recommend terminal emulation software for the PC
that provides DEC VT220 and TEKTRONICS 4105 graphics support
via TCP/IP.

I have heard of several packages, such as EMUTEK? SmarTerm
VTEK, but am having great trouble getting a sensible 
description of these from software distributers.

Any suggestions/reviews/pointers are welcomed. Please EMAIL
to kb@jet.uk and I will post a summary.

Thanks in advance,

		Ken Blackler
-- 
 ______________________________________   ____________   _____________
|Ken Blackler kb@jet.uk (+44)235 464743| | __________ | |   -Fusion-   |
|JET Joint Undertaking, Abingdon       | |   | |_ |   | |Energy for the|
|Oxfordshire, England. OX14 3EA        | | \_/ |_ |   | | (far) future |
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: skl@wimsey.bc.ca (Samuel Lam)
Subject: Re: WinQVT/Net and LanManager not cooperating
Reply-To: skl@wimsey.bc.ca (Samuel Lam)
Date: Mon, 31 Aug 1992 00:54:58 GMT

In article <67055@hydra.gatech.EDU>, bob@comlab.gatech.edu (Bob Baggerman)
 wrote:
>Michael S. Romaniw writes:
>>I can't seem to get QVTnet running with along with LanManager.
>>It always responds to it's own ARP and then complains about a conflict
>>with itself.
>
>...  I have noted this problem with the Ungermann-Bass NDIS
>driver.  ... The UB driver is the only NDIS driver I have found
>that exhibits this aberrent, abhorrent behavior but there may be others.

I encountered this self-broadcast problem with one of the UB NDIS
drivers a few months ago and hacked a quick fix into DIS_PKT9 to get
around it.  However, I never got around to testing the fix out myself,
as the UB card got replaced by a WD card before that.

If anyone is interested in trying the fix out I could post the small
diff here.  No guarantee though, it was a quick Friday night hack.

...Sam
-- 
<skl@wimsey.bc.ca>
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: jms@cs.ufh.ac.za (Inus Scheepers)
Subject: [Help] Working example of BootpTab file for KA9Q, anyone?
Organization: Dept Comp Science, Univ Fort Hare
Date: Thu, 3 Sep 1992 12:02:07 GMT
Summary: Please help me fix the bootptab file for ka9q
Keywords: ka9q, bootp, tcp/ip, bootp database

The KA9Q documentation does not say much about the Bootptab file. Looking
at RFC951 and RFC1048, I tried a couple of permutations, but I still don't
get the bootp server to allocate the desired ip numbers to the specified
hardware addresses. It works OK for dynamically assigning numbers from a
range, but those addresses can disappear when KA9Q is re-started. So, would
someone with a working (non-trivial) version of the bootptab file for NOS
910612 please mail me? Thanks in advance...

--
Inus Scheepers, Dept Comp Science, Univ of Ft Hare, Alice 5700, South Africa
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: EMM386 Execption Erro #12
From: hippo@sonoma.edu (Michel Davidoff)
Date: 4 Sep 92 08:46:49 PDT
Organization: Sonoma state university

When I run marknet and relnet I often get the message 
Emm386 Ececption error # 12 P
And then my system halts. I think that the p is the begining of 
a parity error.
I looked in the DOS 5.0 manual and there is no clue to 
what the error is.
Help ????

Michel Davidoff
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: slp16550 question
Date: 2 Sep 92 19:42:56 GMT
Reply-To: jbvb@ftp.com
Distribution: world
Organization: The Internet


    Is it possible to use the FTP Software slp16550 packet driver with other
    than the PC/TCP kernel? Does it work with Trumpet?

It ought to work with anything that expects a Class 6 driver, but keep
in mind that it's copyrighted software, and we haven't released it as
freeware.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488
From: jrd@cc.usu.edu
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: I NEED DG EMULATION FOR NCSA TELNET
Date: 3 Sep 92 23:06:35 GMT
Followup-To: comp.protocols.tcp-ip.ibmpc
Organization: Utah State University

In article <dave-030992004405@134.29.65.179>, dave@vax2.winona.msus.edu (David Gresham) writes:
> Howdy,
> 
> I am looking for a Data General Emulator that works with NCSA telnet. 
> DG410
> emulation would be best but anything will be preferable to what I,ve got 
> which is nothing.  Also, does anyone know how to get NCSA telnet to coexist
> with PC Support and Novell Netware 3.11 using ODI drivers.  Telnet will not
> work with this other stuff loaded.   
> 
> An answer on E-mail would be prefferable but here is fine too.
> 
> Thanks
> 
> Dave
-------------
Dave,
	What you want exists, but not with NCSA Telnet and near relatives.
If you contact Data General, Mike_Normile@DGC.ceo.dg.com, he will tell you
about a version of MS-DOS Kermit now in development which gives you more than
this: D463 support (with the graphics part remaining to be finished), runs 
Telnet directly over ODI with no shims, provides very wide screen support, 
multiple Telnet sessions, etc. We (the Kermit project) are not formally 
releasing this version until the last parts are completed, hence my directing 
you (and others with similar interests) to Mike Normile.
	Joe D.
From: backman@FTP.COM (Larry Backman)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Trumpet Shell for FTP Software TCP stack.
Date: 23 Aug 92 21:56:08 GMT
Distribution: world
Organization: The Internet



    I thought I would test newsx under Windows. You are right, it appears not to 
    work under Windows Enhanced Mode. Like a lot of my favorite software, it 
    works fine in Windows Standard Mode (just type win /s), which I usually run 
    anyway.
    
    At some point I will take a look at this, but not soon. Does anyone else
    with access to the PCTCP development kit want to look at this? I will 
    happily send source along.
    
    

I can't stand it any more; I give up, I'll dig up the copy of
newsx I have stored away on a tape somewhere and see what's going
on.  I was hoping for mass pilot error, but this is starting to
look like a genuine bug.

Out of curiousity (and please mail direct, not to the list) what
version's of PCTCP are people having problems with.

Larry Backman
FTP Software
Newsgroups: comp.protocols.tcp-ip.ibmpc