From: jrd@cc.usu.edu
Newsgroups: comp.sys.novell
Subject: Re: Networking Saga (Please read last paragraph if nothing else)
Date: 21 Jul 92 19:41:51 MDT
Organization: Utah State University

In article <62349.nygard@mailbox.mail.umn.edu>, nygard@MAILBOX.MAIL.UMN.EDU (Steve Nygard) writes:
> At first setting up a network seemed relatively easy.  Install the cards, 
> fileserver, set up the workstations then enjoy the connectivity.  WRONG.
> 
> Our origional plans were to set up a Novell network, and also use the TCP/IP
> drivers (Clarkson/Crynwr) to allow users access to CUFS (TN3270), AIS, and 
> telnet for Lumina, and of course Gopher and POPmail.  Sounds easy right?
> 
> (Telnet and TN3270 are the NCSA versions obtained from the microcenter)
> 
> I initially used the following configuration with quite a bit of success in 
> a Windows 3.1 environment.
> 
> wd8003e -w -n 0x60 10 0x300 0xcc00
> ipxbyu
> bnetx (and netx)

	That "-w" item says if the application (the Packet Driver client)
is not available when a packet arrives then discard the packet rather than
deliver to the wrong Windows virtual machine. Better than delivering, but
you will lose a lot.

> With this setup I was able to use windows to concurrently access the file 
> server and use any of the TCP/IP driven programs in a full screen DOS 
> window or a windowe'd DOS window.  It was great, no kinks, and never 
> bomb Windows.
> 
> However, ipxbyu is a hack, and not vender supported, and the same with the 
> wd8003e driver.  So in the long run, this is not a very good solution.

	The above, of course, is just an opinion that paying gets better 
quality than for free, something yet to be proven; but I can understand wanting
a warm fuzzy feeling. But do look at what not-paying has brought you.
 
> Then I came across a PS/2 55sx that the wd8003e driver would not recognize 
> so I investigated other methods for TCP/IP support.   Naturally I tried out 
> the packet driver that came with the card. (I am specifically talking 
> about SMC cards)  It was easy to use and you did not have to pass any 
> values to it.  Neat I thought.  But it caused TN3270, or any TCP/IP based 
> programs to bomb Windows, without any warning the user would be dropped 
> back to the C:\ prompt.  Not so good I thought.  I then tried the 8003pkdr 
> driver on the AT bus style computers in the following configuration:
> 
> ipx                                ipx
> netx (and bnetx)            and    8003pkdr
> 8003pkdr                           netx (and bnetx)
> 
> Again, no such luck.  TN3270 sessions would crash windows when the user 
> either switched back to the program manager, or if they windowed the DOS 
> window.  And sometimes just randomly if the user just waited long enough.
> Again the crash was either back to the C:\ prompt or the whole computer 
> just froze.  

	Wrong problem. Windows runs things as virtual machines, that means
the same apparent address is used by different v.m.s at different times.
Without external help any Packet Driver can call the wrong v.m. and that's
the end. What you need is something fairly well known to users by now:
WINPKT.ZIP, available from many places including netlab2.usu.edu, cd misc.
Then omit "-w" on the PD command line.
 
> So I looked for another route.   I sat myself down and read through 300 
> articles in the comp.sys.novell and found two people who looked to have 
> gone through similar situations as me.  I got plenty of help and direction 
> from one of them and he directed me in the use of the ODI drivers.   So I 
> thought, great, ODI, what Novell is most likely moving towards, no more 
> WSGEN, and no more finding the current .obj and .lan files.  
> 
> ODI installed and ready I tried it out.  Seemed simple, but it too mimicked 
> the same Window breaking results.  Back to square 1.

	Meaning, I presume, ODI then ODIPKT on the top to form a Packet
Driver interface again.

> I'm kinda at a loss on how to implement TN3270 for our college or any 
> TCP/IP based program, I was counting on being able to install all the 
> drivers, bring up Windows and let the users connect to any TCP/IP based 
> program and switch between programms. 
> 
> Our file server is an IBM model 80, running Novell 3.11, a SMC MCA Elite 
> Eithernet card, and using frame ETHERNET_802.3.  I have yet to read up on 
> the differences between 802.3 and ethernet_ii  And I tried using 
> ethernet_ii and the configurations above, again, with no success.

	Please do find a chance to read up, and afterward I recommend
ditching the old Novell 802.3 frames for Ethernet_II frames.
 
> Our workstations are PS/2s and IBM 386 clones using the SMC Elite cards.
> (I've tried tons of different configurations on these cards, changing the
>  IRQs, different Memory I/Os, RAM Based addressing, etc... No luck)

	I can't comment on the Microchannel version of things, but so far
the SMC boards work just fine here on ISA bus machines, with Packet Drivers,
and with late model ODI drivers, and I discard SMC's Packet Driver immediately.
 
> My guess is that from the size of this University (and country), someone 
> must be using SMC network cards, running Windows 3.1, AND using TCP/IP 
> support in some manner in which we need to use it.  If you are out there, 
> please contact me.
> ----------------------------------------------------------------------
> Steven Nygard                           Administrative Data Management
> College of Human Ecology                       University of Minnesota
> 1985 Buford Ave, 32 McNeal Hall                 St. Paul Campus, 55018
> internet:nygard@mailbox.mail.umn.edu              BITNET:s-nyga@uminn1
>                                                         (612) 624-3041

	Suggestions. Get WINPKT. Or if you'd prefer to use straight ODI
without a Packet Driver then get either Novell's LWP/DOS or use MS-DOS
Kermit v3.12 beta for Telnet activities. Please don't try to run two or
more TCP/IP applications simulataneously.
	Good luck,
	Joe D.