home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / ibm / 793 next >
Encoding:
Text File  |  1992-11-05  |  2.7 KB  |  61 lines
  1. Newsgroups: comp.protocols.ibm
  2. Path: sparky!uunet!panther!mothost!schbbs!news
  3. From: jmoorhouse@mot.com  (Jim Moorhouse)
  4. Subject: Re: Boycott APPN; Endorse APPI
  5. Reply-To: jmoorhouse@mot.com
  6. Organization: MOTOROLA 
  7. Date: Thu, 5 Nov 1992 15:37:21 GMT
  8. Message-ID: <1992Nov5.153721.22695@schbbs.mot.com>
  9. References: <1992Nov4.213241.25873@mmm.serc.3m.com>
  10. Sender: news@schbbs.mot.com (Net News)
  11. Nntp-Posting-Host: 129.188.149.32
  12. Lines: 47
  13.  
  14. In article <1992Nov4.213241.25873@mmm.serc.3m.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
  15. > Both protocols are equally stupid when you consider the impact on the
  16. > client workstation.  And in the case of APPI, gee, IGRP was a great hit:
  17. > I can get it on  SO many routers.  (Yeah, right!)
  18. > 
  19. > Now the strategy that makes sense is to use OSF DCE or at least get IBM
  20. > to firm up their CPI-C over TCP strategy and then use them to build your
  21. > "blue" applications.
  22.  
  23. I agree whole heartedly, it's time for large vendors to stop talking about Open Systems and start implementing them.
  24. OSF DCE is available now, the only question should be, how fast should legacy systems be migrated to the Open Systems  
  25. environment.  All new applications and products should run in a native Open System environment.  I know this is an over  
  26. simplification but it might start a good discussion.
  27.  
  28. Jim Moorhouse
  29. Motorola
  30. 1299 E. Algonquin Rd.
  31. Schaumburg, Ill.  60196
  32. email jmoorhouse@mot.com
  33. phone (708) 576-0489
  34.  
  35. These opinions are mine and do not necessarily reflect those of Motorola.  
  36. > 
  37. > APPN should never leave the computer room.  Why should I support dual
  38. > stacks all over heck IF I get my blue connectivity over TCP?  And if I
  39. > DO decide I have to have APPN to support my IBM applications, then why on
  40. > earth should I use a tunneling technique rather than a native router? 
  41. > There is a reason they are called multi-protocol routers.  Tunneling 
  42. > causes a performance hit and is a kludge by definition.
  43. > 
  44. > Oh, and by the way, anyone still using IP only routers:  get in the real
  45. > world.  Sometimes business reasons force the issue.  You use the
  46. > protocol that makes sense in the homogeneous environment and TCP to bind
  47. > it all together.  I no more expect to remove SNA from my mainframes as I
  48. > would expect to remove DECnet from my VMS hosts.  They each provide
  49. > functionality that is important to those environment.  But that doesn't
  50. > mean I expect to implement DECnet, SNA, and TCP/IP on all my clients. 
  51. > Let the HOSTS take the burden of running the dual stacks.  Use TCP only
  52. > on the client as much as possible.
  53. > 
  54. > OK, enough spouting:  let the flames begin.
  55. > 
  56. > Charles.
  57. > --
  58. > Charles Ganzhorn            E/Mail:  ccganzhorn@mmm.com
  59. > 3M IS&DP Network Services        AT&T:     +1 612 736 7122
  60. > St. Paul, MN                FAX:     +1 612 736 7689
  61.