HDTenEightyP/NetNews huggingface dataset:
From: jeremy@cowan.edu.au (J.LAIDMAN)
Subject: CUTCP Telnet throwing out to DOS?
Organization: University of Western Australia
Date: Wed, 26 Aug 1992 12:32:01 GMT


I've been using CUTCP Telnet for some time now on a number of machines, net-
work cards, and I'm still getting the same problem.  After a random duration
from, say 10 seconds to 100 minutes, I get thrown out of it back to the DOS
prompt, as if I pressed Alt-F3.

Does anyone else get this?  Is it my setup, local network?  Is there some
spurious packets flying around that cause an end of session?

The same thing happens with the 3270 version.  I'm currently using an NE2000
packet driver, with BYU's IPX to connect to a NW3.11 host.

Help!

---------------------------------------------------------------------
Jeremy Laidman
Edith Cowan University
Department of Computer Science
Perth, Western Australia
Internet: j.laidman@cowan.edu.au
From: garyng@netcom.com (gary )
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: pc-route/pc-bridge, suggestions wanted
Date: 4 Sep 92 13:01:12 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Does anyone have the experience of running pc-route/pc-bridge over a modem 
connection ?

Is pc-bridge/pc-route capable of routing both TCP/IP and NOVELL IPX/SPX 
packets ?

TIA.
-gary
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: stefan@helios.physics.utoronto.ca (Stefan Mochnacki)
Subject: PCROUTE problem: How to suppress SLIP net number propagation?
Organization: University of Toronto Physics/Astronomy/CITA
Date: Fri, 28 Aug 1992 21:28:22 GMT


 PROBLEM:  The SLIP net number, in addition to the remote net number and gateway,
is propagated to the world in a PCROUTE-<SLIP>-PCROUTE
connection to a remote subnet. 
	Furthermore, setting bit 0 in the static route flag for the SLIP
route when using "config.exe" produces the bizarre result that the SLIP
net number is propagated but NOT the remote subnet number; on the remote
ether, the SLIP net number is propagated but not the default gateway (which
stops the link from working ...).

REQUEST: Does anyone know how to suppress propagation of the SLIP 
subnet number so that the same number can be used in many SLIPs on
our campus (we have a shortage of unused Class C net numbers ...)?

CONFIGURATION: Pair of 16 MHz 286's, WD8013EP Elite 16, 16550AF. Internal
PC-ROUTE drivers used.  Version 2.24 of PCROUTE, source, being used.
"0"'s broadcasts being used.

(I would prefer to avoid playing games with netmasks, proxy ARP, etc. I'm
an astronomer, not a net hacker... and our Suns tend to sneeze at such
antics).


-- 
Stefan W. Mochnacki          INTERNET - stefan@centaur.astro.utoronto.ca
Astronomy, U. of Toronto     UUCP - {uunet,pyramid}!utai!helios.physics!stefan
Ph. (416) 884-9562           BITNET - mochnacki@utorphys.bitnet 
FAX (416) 884-2672	     LOCATION - David Dunlap Observatory 
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: tto@aspentec.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: TSRs ...
Date: 3 Sep 92 12:12:05 EST
Distribution: world
Organization: Aspen Technology, Inc. Cambridge, MA.

In article <Btyu2v.AG3@watserv1.uwaterloo.ca>, 
eengelke@sail.uwaterloo.ca (Erick Engelke) writes:

> tto@aspentec.com writes:
>>...
>>Yes, many developers have no idea how to do things properly in the DOS
>>environment, let alone making programs suitable for a TSR.  E.g., Sun's
>>PC/NFS uses malloc() and DEC's Pathwork TCP/IP (written by 3Com) traps
>>INT 2F (AX=1122) and promptly undoes itself whenever one issues an
>>INT 21 (AH=31) to terminate and stay resident!
> 
> HP and 3com co-developed that product and it seems to have Microsoft
> involved somehow.  Since I've only dealt with the tech staff, we were
> all quite uncertain how many lawyers it takes to write a network stack.

:-) And it is real fun when one calls DEC up about problems in these
programs!

> Anyways, it's a bit of a challenge to TSRize their programs.  You must
> write a function with the same name as their function which intercepts
> the int 2f interceptor to prevent this from happenning.  That one caught
> me by surprise too.  But I didn't think it was widespread enough
> a system to comment on it, but it took me a day to figure out.

I took a different tack.  I intercepted INT 2F (AX=1122) myself, bypassed
their exit handler when I installed the TSR, and activated their exit
handler when I deinstalled the TSR.  I did not want to change my code
again when they decided to modify their exit handler in the future.
 
Caveat: apparently inside a handler for INT 2F (AX=1122) one cannot
call INT 21 (AH=25) to change interrupt vectors.  One must modify the
memory locations directly or DOS will be very confused.

>>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.  I don't mind
> doing the work, but when it cuts into processor performance or carves
> out more memory, I start looking at new solutions.

In general I just do everything with my TSR's PSP.  It simplifies things
in the long run.

Tak.
-----------------------------------------------------------------------------
Tak To                                                    (617) 497-9020 x377
Aspen Technology, Inc                                Fax: (617) 497-7806
243 Vassar St, Cambridge, Ma 02139.                       tto@aspentec.com
-----------------------------------------------------------------------------
From: cbt@cam-orl.co.uk (Chris B Turner)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: When do we get PC-NFS dev kit for Windows?
Date: 4 Sep 92 10:20:08 GMT
Organization: Olivetti Research Ltd


I've had an order on Unipalm UK for ages now for the promised PC-NFS
developers kit version 4 that will let us write Windows 3.x apps. I
guess that the socket API will be similar to the winsock proposals and
willl be implimented by a DLL so all that old DOS TSR before Windows
stuff will become history. But Unipalm still don't have the kit to
deliver, despite promises ages ago from Sun. What's hapopening out
there? Does anyone have this kit yet? Will it impliment the winsock
API? Will it provide the PC-NFS version of winsock.dll????
-- 
-----------------------------------------------------------------------------
Chris Turner cbt@cam-orl.co.uk
Olivetti Research Laboratory        If it doesn't smell it isn't multimedia!
Cambridge. England
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: rsemenof@ee.ubc.ca (SEMENOFF ROBERT)
Subject: slip8250 packet driver :  works ?
Organization: University of BC, Electrical Engineering
Date: Tue, 1 Sep 1992 04:04:50 GMT

If there's anyone out there who's used this packet driver,
I'd really appreciate a quick note saying that it does
actually work as advertised.

Sorry for the dumb question, but I just want to make
sure I'm pounding my head against a subtle error in my
pd client program.
P.S. I'm using the very latest version, as is.

Thanks in advance for any response.
--
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Routines/Libraries to allow communications between PC's using C programs
Date: 25 Aug 92 13:19:37 GMT
Reply-To: jbvb@ftp.com
Organization: The Internet


    Is there any software libraries or routines available (commercial or
    public domain) that will allow communicaitons between programs.

We (like the other commercial DOS TCP/IP vendors) sell a development
environment for our package.  It's part PC-502.  We include a 4bsd-
compatible socket API library.  We use it to build our own commercial
applications, and support it via phone and net.  The API manual is
available separately.  The API is also partially described in the
"Interrupt List", although I don't know of anyone who's actually
tried to program from that.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.sys.sun.misc
From: david@softwords.bc.ca (David Hume)
Subject: PC-NFS 4.0 problem with DOS file compression programs
Summary: corruption of files if done on a network drive
Keywords: PCNFS, PKZIP, InstallShield, corruption, 4.0
Organization: Softwords Research International
Date: Fri, 28 Aug 92 17:47:29 GMT

We seem to be having a problem here, having upgraded to 4.0 (one machine
upgraded, one newly installed) with some DOS software...

Specifically, if you use the compression programs PKZIP or InstallShield
"compress", *on* the network drive to compress, the resulting uncompress
action results in a corrup file. Compress on the local hardrive first,
there is no problem.

We were able to compress with these programs on the network drive with no
corruption with 3.5 

Has anyone else encountered this? Any suggestions as to what might be wrong
with out configuration to cause this, or is there a known bug...

Much appreciated.


****************************************************************************
* David E. Hume		! "And if I die today, I'll be the Happy Phantom   *
* david@softwords.bc.ca !   and I will go chasing nuns out in the yard"    *
* Softwords		!                                                  *
* Victoria, BC, Canada  !          - Tori Amos                             *
*                       !                                                  *
****************************************************************************
From: tto@aspentec.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: TSRs ...
Date: 4 Sep 92 12:54:43 EST
Distribution: world
Organization: Aspen Technology, Inc. Cambridge, MA.

In article <1873f3INNk31@seven-up.East.Sun.COM>, 
 geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
 
> 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".)

Yes, I was over-simplifying things a little bit.  They are not compatible
with DOS' file descriptors but they are global nonetheless (i.e., they can be
used by any process).

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

There is definitely a trade off here.  While I think Sun did a decent job
in making socket descriptors look like DOS file descriptors, I tend to agree
with Erick that since [real mode] memory is such a premium in DOS, the less
code the better.  As for porting code from Unix, if one is not using high
level procedures such as fprintf(), wouldn't something like "#define
read(...) socket_read(...)" be sufficient?

> And if sockets
> are (DOS) files, then you can't get around the need to switch PSP's.

For the general readers: there is actually a fairly easy way to share DOS
file descriptors without switching PSPs.  E.g., say that process B needs to
access process A's file descriptor <i>.  One can look up the <i>th slot in the
descriptor table in A's PSP and copy the _global_ file descriptor stored there
into an unused slot (say, the <j>th slot) in B's descriptor table.  Now process
B can access the file via file descriptor <j>.  NB: Use with caution.

Tak.
-----------------------------------------------------------------------------
Tak To                                                    (617) 497-9020 x377
Aspen Technology, Inc                                Fax: (617) 497-7806
243 Vassar St, Cambridge, Ma 02139.                       tto@aspentec.com
-----------------------------------------------------------------------------
"The best operating system?  ITS, of course!"                       alt-alt-u
From: dan@dribble.c-mols.siu.edu (Dan Ellison)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: TN3270 under windows
Date: 4 Sep 92 15:33:58 GMT
Organization: Southern Illinois University - Carbondale, IL (SIU-C)

In <9209021606.aa25817@louie.udel.edu> OSG0305@UNLVM.UNL.EDU (Nancy Davis) writes:


>Is there a product available for running TN3270 under Windows?
>Thanks for the info.

>Nancy Davis                      OSG0305@UNLVM
>Computing Services Network       OSG0305@UNLVM.UNL.EDU
>Univ. of Nebraska-Lincoln

Actually, there are several options to accomplish this.  If you want
to spend $400 you can get PerComm (personal communications) package.
It runs under windows as an SNA product.  Alternatively, you can get
a Clarkson packet driver for your interface card and either winpkt
or pktmux.  Install one or the other of these over the packet driver.
Then, when in windows, create a batch file that will install a new
pktdrv under pktmux and start tn3270 in a DOS window.  The trick is
to put together a pif file to launch the batch file and allow the
DOS session to run in the background (advanced options of the pif
editor.)  If you don't do this then messages from VM will surely
crash the session.  Once you get background operation working the
VM messages will no longer effect the session and things will work
beautifully.  This is the setup I use and it pleases me just fine.

Good luck with it.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Dan Ellison, Network Team 	  -    	Computing Affairs, SIU-C 	| 
| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-6149 	|
From: bob@comlab.gatech.edu (Bob Baggerman)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: WinQVT/Net and LanManager not cooperating
Date: 27 Aug 92 19:56:33 GMT
Organization: Georgia Institute of Technology

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.

The thing that was not mentioned was the ethernet hardware and NDIS 
driver used.  I have noted this problem with the Ungermann-Bass NDIS
driver.  In the case of NCSA Telnet, the solution is to turn on the 
"noarpme" switch.  The UB driver is the only NDIS driver I have found
that exhibits this aberrent, abhorrent behavior but there may be others.
It would be nice if QVTnet also supported "noarpme".

Bob

--
Bob Baggerman                         !  bob.baggerman@gtri.gatech.edu
Communications Laboratory             !  bob@comlab.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525
From: boyken@herky.cs.uiowa.edu (Karl Boyken)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: NCSA Telnet & WINPKT
Date: 4 Sep 92 18:42:22 GMT
Organization: Dept. of Comp. Sci., U. of Iowa

I've set up a number of PCs with NCSA Telnet and Windows, using WINPKT.
For the packet driver, I always use 0x62 for the packet interrupt, then use

     winpkt 0x60 0x62

to start WINPKT.  WINPKT says that it finds the packet driver and that the
new interrupt is 0x60.  I configure the config.tel thus:

     hardware=packet
     interrupt=60

But, when I start Telnet in Windows, I always get this message:

     Warning, packet driver vector incorrect, using default search

Telnet evidentally does find an interrupt, but I'd prefer that it didn't have
to search for it.

If I don't load WINPKT and change the packet driver invocation to 0x60,
Telnet starts up without the warning.

What am I doing wrong?  Thanks in advance.

*****        _My_ views, no one else's--except those I plagiarize         *****
Karl Boyken, system programmer | Distant cousins, there's a limited supply, and
Department of Computer Science | we're down to the dozens, and this is why:
The University of Iowa         | big-eyed beans from Venus--oh my, oh my!
boyken@herky.cs.uiowa.edu      |                           -- Captain Beefheart
From: ken@faculty.law.duke.edu (Ken Hirsh)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Help with Abend cause
Date: 2 Sep 92 13:56:13 GMT
Organization: Duke University School of Law


 

I'm running Netware 3.11 on a Zenith 386/25 with 7 megs RAM.  I
recently upgraded the disk controller to an Ultrastor 12F24 and
the drive to a Micropolis 345 MB drive.
Every 2 or 3 days I am getting an ABEND with this message:
Nonmaskable Interrupt (Parity Error) Processor Exception.
Parity Error was generated by an I/O check.
Running Process: Interrupt Service Routine (nested count 2).
Interrupted Process: Server 03 process.
Can some of you help me find the specific cause of this problem?
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: thayne@unislc.uucp (Thayne Forbes)
Subject: Re: Good TCP/IP package for NFS and with SCO ansi emulation.
X-Newsreader: Tin 1.1 PL5
Organization: HomeVax
Date: Thu, 3 Sep 1992 23:54:22 GMT

James B. Van Bokkelen (jbvb@FTP.COM) wrote:
: 
:     TNGLASS handles the colors, but not the line drawing, and VT100 sequences
:     don't appear to map completely to just ANSI.SYS.
: 
: I don't know if it's still available, but there used to be a shareware program
: called FANSI Console, which was a greatly-improved ANSI.SYS.  You could also
: use a 3rd party commercial terminal emulator which supported both the
: VT100-style escape sequences and ANSI.SYS colors, but I don't know of one
: off-hand.

I do.  I think either TERM or TinyTERM from Century Software will solve your
problem.  They will both do the previous posters request as well.

-- 
           "If we don't succeed, we run the risk of failure."
                            -U.S. Vice President J. Danforth Quayl[e]
Thayne Forbes
thayne@unislc.slc.unisys.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: glowe@nyx.cs.du.edu (Glen Lowe)
Subject: Re: slip8250 packet driver :  works ?
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Tue, 1 Sep 92 07:28:19 GMT


I was able to get it to work with winqvtnet at speeds < 2400 baud..
at higher speeds qvtnet crashes with a gpe... 
glen
?5i
From: bruno@broue.rot.qc.ca (Bruno Majewski)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: problems with PC/TCP's NFS
Date: 25 Aug 92 17:49:21 GMT
Distribution: world
Organization: Groupe de Recherche Operationnelle en Telecommunication (ROT)
X-Newsreader: Tin 1.1 PL4


Hello,

(a message concerning this problem was posted a few days ago,
 but because of disk problems on our machine, it might not have
 gone out... so here I go again)

We are using FTP Software's PC/TCP package to network a few PCs onto
a UNIX server, but we have a small problem with it. While the performance 
of the setup is good, mounting a... "network drive" on the PC is unacceptably
slow (I timed this at 35-40 seconds to perform an `idmnt').

We thought it might be the server being too slow (386-33), but a Macintosh
using NFS/Share from Intercon can mount a "network volume" almost instantly.
So the problem seems to lie with the PC's setup, but we can't see what 
parameter could affect performance in such a way.

I have placed a call at FTP Software, who refered me to my local distributor;
he never heard of such a problem and could not help me. Anyone of you people
out there ever experienced something like this?

FYI, here is our setup:

server running Interactive Systems Corporation UNIX System V/386 rel. 3.2,
  it is a 386-33 with 8 Mb RAM

each pc is a 386-25 with 4/8 Mb RAM,
  there are running PC/TCP 2.05

Our net is running over 10base-T .


Thanks in advance to all who will answer.

----------------------+-----------------------------------------------------+
Bruno Majewski        | Groupe de Recherche Operationnelle en               |
                      |   Telecommunication (R.O.T.)                        |
bruno@broue.rot.qc.ca +-----------------------------------------------------+
                      | also @: Synerlogic Inc, div. of Andersen Consulting |
                      |         Voice: (514) 685-7575                       |
                      |         FAX  : (514) 685-7692                       |
----------------------+-----------------------------------------------------+
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: tcp-ip library nonblocking I/O (Berkeley compatible)?
Date: 1 Sep 92 17:05:25 GMT
Reply-To: jbvb@ftp.com
Organization: The Internet


    Yes, with one exception.  I believe FTP's PC/TCP does not support the
    use of select to asynchronously detect the establishment of a connection
    on a listenning socket.  Someone will surely correct me if I'm wrong.

Unless the code is buggy (and inspection doesn't reveal anything obvious),
we should report a listening socket with connections available for accept()
as readable.

    If you plan for this to work as a TSR, there are a lot of big sacrifices
    to make, and you would be best off to drop any thought of starting
    with UNIX code.

Amen.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488
*note new address & phone*
From: JOCELYN@novl1.ci.cuslm.ca (Jocelyn Nadeau)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Any PD based NSLOOKUPs around?
Date: 26 Aug 92 12:13:01 GMT
Reply-To: jocelyn@cuslm.ca
Distribution: world
Organization: Centre univ. Saint-Louis-Maillet

Bonjour,

There's one for the Mac just out.  It's called Query it! and it's by Chris
McNeil.  I think it's on SUMEX.  I got it directly from Chris so I'm not
sure if he uploaded it to SUMEX yet but it's probable.

Salut

Jocelyn
------------------------------------------------------------------------
Jocelyn Nadeau                                   Jocelyn@cuslm.ca
Centre universitaire Saint-Louis-Maillet         506-737-5050 ext 5277
Edmundston, NB Canada                            fax 506-739-5373
E3V 2S8
------------------------------------------------------------------------
From: pronk@cs.few.eur.nl (Hans Pronk)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: email address Beame & Whiteside
Date: 26 Aug 92 07:08:43 GMT
Organization: Erasmus Universiteit Rotterdam

I am looking for the email address of Beame & Whiteside Software Ltd

Hans M. Pronk.
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: drichard@magnus.acs.ohio-state.edu (Darren R Richardson)
Subject: NNTP server
Organization: The Ohio State University
Date: Fri, 4 Sep 1992 18:08:16 GMT

Does anybody know of a DOS based NNTP server program (shareware would be best)? If so where can I locate it?  If not, is there one that will run under VMS?
 
-- 
 Darren Richardson
 Ohio State University
 College of Engineering
 CIS Consultant
From: maximn@gate.dialnet.msk.su (Maxim Nikitin)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: NetWare and Packet Drivers
Date: 23 Aug 92 18:27:00 GMT
Organization: NetDialogue (Gid:gate.dialnet.msk.su)
X-Gate: UU2 1.11a


                                Hi, All!

        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?

        Thanks in advance.
        The best regards, Maxim.

--- D'Bridge B1072 + GoldED 2.40.P0621+
 * Origin: Stealth Voice BBS, Novosibirsk, Russia (FidoNet 2:5000/30)