jb@mytardis.UUCP (John Bartas) (08/01/90)
Doug Harvey writes: >I've got several applications in mind that would work great if I could >connect two OS/2 workstations across our Token Ring LAN. > >We are running OS/2 EE v1.2 on IBM PS/2 70's with 120MB and 10MB+ RAM. >Also, our LAN software is IBM LAN Server v1.2. > >What I want to do: > >Be able to connect any two workstations together so they can "talk", >whatever that might mean (up to the application). > >What I've tried: > >Experimented with named pipes, but it doesn't look like I can connect >(from a requester) to a named pipe that resides on another requester. >The named pipe has to be on a server. > >I think APPC would do the job, but APPC imposed quite a bit of overhead, >both in terms of running it, and coding the application. . . . . . >Doug Harvey >-- >Hewitt Associates >100 Half Day Road >Lincolnshire, IL 60069 >(708) 295-5000 Doug; One quick solution to your problem would be to use comercial TCP/IP packages. These are now available for OS/2 over token ring, and I think most of them include the Sockets API. Sockets is a de-facto standard for calling TCP/IP fuctions in UNIX systems and as such supports peer to peer connections of the type you need. You have touched on a basic flaw in the Lan Manager model of Networking: the artificial division of clients (or as IBM likes to call them "requestors") and servers. On most non-PC oriented networks, (ie tcp/ip) every machine is logically a peer of every other machine, so they each have the option of beening client or server or both. There is no technical reason why two OS/2 requestors couldn't communicate via named pipes. This restriction is imposed for a variety of marketing reasons. You may have seen rumors in PC trade rags that TCP/IP is slow or hard to use. These rumors are (I think) perpetuated by big companies who want to lock you into their proprietary protocols. A good TCP/IP stack is about as fast and much more versatile than any of the "PC-only" networks. FTP Software Inc. (ph# 617-868-3878) is a reputable supplier of TCP/IP products which has just released an OS/2 product. The Wollongong Group (415 962-7100) has a product in Alpha test. I know there are other vendors, but I don't have the phone numbers handy. You don't mention a budget for your projects, so I suspect the prices ($575 for FTP's OS/2 product in single quantities, probably similar for their competitors) may be a problem. But at least you can threaten your IBM/Microsft salesperson with buying peer-to-peer APIs from third parties; and maybe someday they will allow it in named pipes. One last thought: The july 8th issue of Network World had an article on Token Ring software products which included a usefull table describing features and price of many OS/2 products (I got the FTP info there). The article started by asserting that 16Mb Token Ring would be cost competitive with ethernet in less than a year (which I would bet a LOT of money against) but once you get past that it contains a lot of usefull information. I noticed several products claiming peer to peer connectivity, so you may find other solutions there. Another last thought: The 3com 3+open Lan Manager provided a NetBios API which supported peer to peer connections. Does your IBM product include a NetBios API? An application written to this would be very portable to other OS/2 platforms and you may already have all the software you need. Good Luck! -JB- ----------------------------------------------------------------------- John Bartas | This space for rent. NetPort Software |
oleg@ibm.com (08/02/90)
The three vendors that sell TCP/IP products for OS/2 are IBM, FTP Software, and Essex systems. Last month PC WEEK had an article comparing them. FTP Software provides sockets. IBM APIs include sockets, RPC, NCS, and KERBEROS. Not sure about Essex but most likely they do, too. Oleg Vishnepolsky IBM T. J. Watson Research Center
root@dialog.stgt.sub.org (Christian Motz) (08/26/90)
>Doug Harvey writes: > >> [...] >> >>I think APPC would do the job, but APPC imposed quite a bit of overhead, >>both in terms of running it, and coding the application. APPC will indeed do the job -- I am not sure what you are referring to with the overhead. The only real "overhead" with APPC is that you have to have the Communications Manager up and running. Once this is the case, the remaining overhead is not really that big. Coding an APPC Transaction Program under OS/2 is not really that big a problem, since the API for it is rather easy to use, and with, let's say 700 lines or so of code you could write yourself an interface which basically is as easy to use as file I/O functions or sockets under UN*X for that matter. The advantage of using APPC is that you do not need yet another communications package to achieve the desired functionality. Besides, if you are using remote data services in a LAN, CM is up and running anyway, so you can just as well use it anyway. If anyone is interested, I can elaborate on the usage of APPC a bit. Just drop me a line at the above address and I will get back to you, mailers willing. -- Christian Motz root@dialog.stgt.sub.org