aad@stpstn.UUCP (Anthony A. Datri) (06/26/88)
If DEC really wanted to exist peacefully in a multivendor, ethernet environment, they'd at least supply a TCP/IP product for VMS, as well as a termcap. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is beak is not Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
rrk@byuvax.bitnet (06/28/88)
It has never been DEC's intention to exist "peacefully" in the multi vendor environment. They wzant to be the hub of the multi vendor network.
IMHW400@INDYVAX.BITNET (07/05/88)
>From: "Anthony A. Datri" <oliveb!bunker!stpstn!aad@ames.arc.nasa.gov> >If DEC really wanted to exist peacefully in a multivendor, ethernet >environment, they'd at least supply a TCP/IP product for VMS, as well >as a termcap. DEC *does* supply TCP/IP for VMS: they remarket both Wollongong's WINS and Network Research's FUSION. If you are willing to admit Ultrix systems as well, DEC currently sells *three* different TCP/IP packages. Why don't they come up with their own? My guess is twofold: 1) They need to have all of their network wizards working on DECnet Phase V, to provide VMS with the complete OSI protocol stack (as complete as the stack of standards, anyway). 2) I am guessing that DEC sees TCP/IP becoming a niche market as OSI phases in across the industry, a small market that they'd rather leave to others with more experience and existing investment. ARPANET/MILNET, for example, is going to have to move to the OSI stack unless they can invoke some kind of escape clause to evade GOSIP, and I imagine that the rest of the Internet will follow. I imagine that most TCP/IP vendors are quietly working out a plan to move their products to the OSI stack, and eventually phase out TCP/IP (maybe maintaining the popular user interfaces, with support from the new protocol services). Why spend all that money on a product for which you expect steadily DEcreasing sales? Note 1: I don't work for DEC, I don't have access to their unannounced policies, and my crystal ball is often cloudy. Note 2: Flames on the subject of TCP/IP's useful lifetime, merits relative to the OSI stack, and other such religious issues should be directed to me personally; I don't want to stir up another holy war. ******** As for termcap, it is available as part of DEC/Shell, which is a handy gadget in a number of ways. Also, look at the SMG$ stuff for a VMS-native equivalent. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mark H. Wood IMHW400@INDYVAX.BITNET (317)274-0749 III U U PPPP U U III Indiana University - Purdue University at Indianapolis I U U P P U U I 799 West Michigan Street, ET 1023 I U U PPPP U U I Indianapolis, IN 46202 USA I U U P U U I [@disclaimer@] III UUU P UUU III
reden@sys1.TANDY.COM (07/17/88)
>It has never been DEC's intention to exist "peacefully" in the multi vendor >environment. They wzant to be the hub of the multi vendor network. That's what worries me about OSI. I think that a true - everybody can talk to anybody - network will still be a pipe dream. (other than TCP/IP) I thought X Windows would standardize terminal communications. I recenetly attended a DECWindows seminar and guess what X uses for communications........ a DECNET object. I aggree that this procedure is the "proper" way to do such a thing but I bet if I had a Sun workstation running DECNET and X the SUN couldn't be a X server for the VAX. At least not without figuring out how DEC's X network object works and writing one for the SUN. The idea is going the right way, but I can't see vendors getting togeather without adding "enhancments" to screw it all up. Robert reden@sys1.uucp
MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (07/21/88)
> Date: Tuesday, June 28, 1988 at 4:16 pm gmt > From: "jade.berkeley.edu.user" <cunyvm!unknown%psuvm.BITNET@HOST> > Subj: Re: Press Release > > It has never been DEC's intention to exist "peacefully" in the multi vendor > environment. They want to be the hub of the multi vendor network. * Flame ON * Well, we started DEC. We bought Message Router, Digital's electronic mail transport system. Our staff is using ALL-IN-1, which uses Message Router to transport its network mail. But to make it work with DECnet mail, we had to put contorted forwarding VMSmail addresses in for everyone. But to participate in BITNET we use Jnet, by Joiner Associates, an excellent peer-to-peer DEC-IBM networking product. (Where is your product, Digital?) Jnet doesn't support Message Router. To make Jnet work with ALL-IN-1 we had to modify ALL-IN-1. We want to send mail through BITNET gateways to other networks. Jnet doesn't do it so ALL-IN-1 won't do it. Neither does VMSmail for that matter. Furthermore, we couldn't put 1200 students into ALL-IN-1 mail without buying enough VAXen to run the NYSE. So students use Dreams/6, by DCXX Software Services, an excellent personal mail system and mail transport system. It works well with DECnet and Jnet and supports RFC822, BSMTP and BITNET gateways. (Where is your product, Digital?) It doesn't support Message Router. In order to get mail from Message Router we had to modify VMSmail. Even so, a Dreams/6 user can't reply to a memo received from Message Router because the return address is munged. To participate in a TCP/IP LAN we got CMU-TEK TCP/IP, by Carnegie Mellon University. (Where is your product, Digital?) It doesn't support Message Router. Dreams/6 doesn't support CMU-TEK. What will? PMDF, from Ned Freed. (Where is your product, Digital?) It doesn't work with Message Router. At the hub of multivendor networking? Poop, I say, Digital. Poop. * Flame OFF * Ed
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/27/88)
Well, we started DEC. We bought Message Router, Digital's electronic mail transport system. Our staff is using ALL-IN-1, which uses Message Router to transport its network mail. But to make it work with DECnet mail, we had to put contorted forwarding VMSmail addresses in for everyone. But to participate in BITNET we use Jnet, by Joiner Associates, an excellent peer-to-peer DEC-IBM networking product. (Where is your product, Digital?) Jnet doesn't support Message Router. To make Jnet work with ALL-IN-1 we had to modify ALL-IN-1. We want to send mail through BITNET gateways to other networks. Jnet doesn't do it so ALL-IN-1 won't do it. Neither does VMSmail for that matter. Furthermore, we couldn't put 1200 students into ALL-IN-1 mail without buying enough VAXen to run the NYSE. So students use Dreams/6, by DCXX Software Services, an excellent personal mail system and mail transport system. It works well with DECnet and Jnet and supports RFC822, BSMTP and BITNET gateways. (Where is your product, Digital?) It doesn't support Message Router. In order to get mail from Message Router we had to modify VMSmail. Even so, a Dreams/6 user can't reply to a memo received from Message Router because the return address is munged. To participate in a TCP/IP LAN we got CMU-TEK TCP/IP, by Carnegie Mellon University. (Where is your product, Digital?) It doesn't support Message Router. Dreams/6 doesn't support CMU-TEK. What will? PMDF, from Ned Freed. (Where is your product, Digital?) It doesn't work with Message Router. At the hub of multivendor networking? Poop, I say, Digital. Poop. Let's get real here. There's a great Gordon Bell quote about standards (from well after he left Digital - it refers to the whole industry): We think standards are so great we keep creating new ones. You've listed, let's see, VMSMAIL, ALL-IN-1 MAIL/Message Router, BITNET, RFC822, BSMTP, hence IBM networking protocols, DECnet, TCP/IP. You could have listed UUCP/News, other IBM protocols (SNA, Profs), and who knows what else. No one company could possibly support all this stuff. You might as well flame at IBM for not supporting either DECnet or TCP/IP or UUCP (that would let you get rid of the BITNET stuff) or generic Unix for not supporting TCP/IP exclusively and retiring UUCP or .... You have one very legitimate complaint (the lack of compatibility between VMSMAIL and ALL-IN-1), an unfortunate legacy (VMSMAIL just kind of grew, pre- dating most current standards, and it's just too limited to play in today's world without the warts showing through) - but at least there are workarounds. TCP/IP is also a sore spot, but why do you care WHO writes the code, provided that it is available? DEC resells two 3rd-party TCP/IP packages (Wollongong and I think Fusion). There are announced standards for networks and mail systems (the ISO stuff, X.400) which DEC has announced it intends to support. In fact, it supports X.400 TODAY. Why not flame at IBM and all your other vendors for not being up-to-date and supporting X.400? As a matter of fact, DEC sells a number of products to interconnect with IBM systems. IBM systems themselves support such a multiplicity of protocols that you could come up with a similar litany of complaints just for talking to them. Much as I understand the difficulties and frustrations of building networks on top of the huge variety of "standards" in existence today, I think your complaints are mainly misdirected. If Joiner's stuff won't talk to Message Router, why don't you complain to Joiner? They are at least an equal part of the problem. If Dreams/6 won't talk to CMU/TEK, why not complain to DCXX? If PMDF won't talk to Message Router, well, I won't suggest complaining to Ned Freed - he's not paid for doing the excellent job he's done - why not get someone to write you a Message Router channel program? I'll bet it's easier to do than many of the hacks you've already got thrown together, and you'll certainly find a lot of people out there who would LOVE to have it. (They might even be willing to pay.) The ONLY way out of this mess is to chose a single set of protocols and stick with it. The current mish-mash of small fiefdoms and special-purpose hacks cannot work in the long term. There are four conceivable contenders for this kind of role: DECnet, SNA, TCP/IP, and OSI. DEC has already announced that has no intention of pushing DECnet as THE standard, but will merge with OSI. Outside of the IBM world, the chances of SNA taking over are essentially nil (though within the IBM world, it'll likely be around forever). The TCP/IP vs. OSI battle has been heated in the past, and there's no point in rehashing it; but I think even the most ardent TCP/IP supporter will have to concede that, whatever the technical merits, OSI has won (except within the academic community, and there it's probably just a matter of time). We can only hope that five, ten years from now the network interconnect problems of today will be dimly remembered by the "old fogeys" like us; the newcomers will just plug stuff in, just as we plug in appliances without worrying about AC vs. DC, 60Hz vs. 50Hz. The transition phase will, however, be painful. To expect anyone to pour large amounts of manpower and money into providing short-term hacks, when they could be trying to build stuff with a future, is foolish. -- Jerry [Who expects to be flamed by all the TCP/IP patriots and such :-)]
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/27/88)
By an interesting coincidence, just after writing my previous message, I came across the following message in the PMFD mailing list. -- Jerry NEWS-Posting: Newsgroup <mail.pmdf>, Item <#406>, Subject <Re: Capabilities of PMDF?> Received: from JNET-DAEMON by Venus.YCC.Yale.Edu; Wed, 27 Jul 88 04:34 EST Received: From YMIR(NED) by YALEVMS with Jnet id 7462 for PMDF@YALEVMS; Wed, 27 Jul 88 04:34 EST Date: Wed, 27 Jul 88 00:40 PDT From: Ned Freed <NED@YMIR.BITNET> Subject: Re: Capabilities of PMDF? To: info-pmdf@YMIR.BITNET, vms-pmdf@relay.cs.net X-VMS-To: IPMDF,VPMDF Resent-date: Wed, 27 Jul 88 00:42 PDT Resent-to: INFO-PMDF-LIST@YMIR.BITNET Path: venus!newsmgr Newsgroups: mail.pmdf Approved: newsmgr@venus.ycc.yale.edu Message-ID: <880727044752.0000380C@venus.ycc.yale.edu> Lau Kai Cheong writes: > Hi! I was told by Ned to send my queries here and hope that > experienced PMDF users out there can help me answer these > questions. > We recently began using Jnet and Gmail. We interface Jnet with > All-in-1 to send mail to bitnet nodes. To reach nodes on other > non-bitnet nodes, we have to rely on Gmail. I have heard about > PMDF which seems to me offer a better interface to VMS. > 1. I was told by Ned that PMDF interfaces to VMS mail directly. > One can reply to a PMDF message in VMS mail by using the REPLY > command in VMS mail directly. Well, presently without PMDF we > are also able to do that, but only for replying to mail form > bitnet nodes. If the reply is to a mail from non-bitnet nodes, > we have to specifically invoke Gmail to do that. So my question > is, can PMDF handle replies to non-bitnet nodes using VMS REPLY > command? Yes, you can reply to both BITNET and non-BITNET messages with PMDF. > 2. > (i) This question is more for users who have used PMDF with > All-in-1. Can we send mail to both bitnet and non-bitnet nodes > using All-in-1? We are using All-in-1 for messaging. Presently > Jnet's interface with All-in-1 only recognise bitnet addresses. > It will tell you that it does not recognise an ARPANET > address,for eg. if you send a mail via All-in-1 to a node on > ARPANET. Since All-in-1 mail ultimately goes to VMS, is there an > interface between PMDF and All-in-1 so that it is able to > recognise ARPANET's addressing scheme and sent it correctly? To > overcome the above problem, we now send mail to bitnet nodes > using All-in-1 and to send mail to non-bitnet nodes, we have to > get to VMS and invoke Gmail to send, which you will agree is not > neat at all. > (ii) If there is an interface between PMDF and All-in-1, can we > use All-in-1's answer feature to reply to a mail? Right now, > Jnet does not allow that, so we have to create a new mail > everytime to reply to a mail. This applies to replies to mail > from bitnet and non-bitnet nodes. The only problem with using All-in-1 with PMDF is that All-in-1 has some funny restrictions on address formats that cause it to have problems with PMDF addresses. This issue has been discussed at some length on the info-pmdf list in the past, and the solution appears to be to make a simple modification to one of the .COM files in All-in-1. I do not run All-in-1 here so I cannot vouch for this, but several sites have reported that it works fine. The archives of info-pmdf messages are included in the PMDF distribution, so you can go back and track down all the details of the discussion if you want to. > (iii) Has anybody installed Jnet, TCP/IP and PMDF on a VAX > system before? If so, have they configured the TCP mailer to > allow bitnet mail to be rerouted from the VAX to a SUN > automatically? This is done all the time. We do it here with a variety of hosts, including a SUN. > We would definitely switch to PMDF if these needs can be met or > would consider if there are any other benefits that could be > gained from doing so. The advantage of using GMAIL is that it is quite simple to install and maintain. In a situation where you have a single, isolated VAX that just communicates via JNET to BITNET and has no system management to speak of, GMAIL may be a big win. PMDF is not so easy to install, since it is quite general-purpose and not specialized as a BITNET mailer for VAXes. You have to pay some attention to how it is set up and you should take some time periodically to update its configuration file. But if you have more than one network to deal with, PMDF is worth it since it provides the facilities to route messages among any number of networks. Ned
MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (07/27/88)
Digital's track record in multivendor networking is poor. If Digital is committed to being the hub of multivendor networking, why should I blame the other vendors for this problem? I simply don't believe Digital is committed to multivendor networking except where it is forced into it by the presence of IBM. Standardization is the future solution, but Digital has no solutions for us in the present. At Grinnell, our most important multivendor application is electronic mail. Digital's flagship electronic mail system for VMS (Message Router/MailBus) is supported by none of the other vendors our equipment is connected to. If Digital were committed to multivendor networking, it would say `we support the industry standard protocols that you use.' Instead it says `we support our own nonstandard protocol but you can buy a development package from us and write your own link to our nonstandard software.' We're using TCP/IP and SMTP today. We're using NJE and RSCS today. OSI? Oh, Still Incomplete. ISDN? I Still Don't Know. Marketing Wollongong's TCP/IP is not a solution. It doesn't work well with DECnet or Message Router. It's no good to have all the pieces if none of them work together. It's not enough for Digital to market SNA Gateway. How many VMS nodes on BITNET are interconnected using SNA? Why should I depend upon Joiner Associates for Message Router support in Jnet/NJE? The real problem is that Digital doesn't have any product. Ed
jkingdon@chinet.chi.il.us (James Kingdon) (07/28/88)
This is in response to the person who described many trials and tribulations trying to use DEC stuff with anything not made my DEC. When I was working at Oberlin College we wanted to try connect our VMS system to BITNET, DecNET, the computer science UNIX machine, etc. After trying a few things that didn't work so well we put up PMDF, and found it was a VERY useful mailer. It hooks up very nicely with JNET, with many different TCP/IP implementations, with UNIX machines running PMDF, CMDF, or MMDF (all of which are more or less free, I think), with the Macintosh running MacPMDF (MacPMDF does lack a very good mail reader but the one provided is useable), other VMS machines running PMDF over DecNET, and probably others I forgot to mention. So for mail anyway, this is probably the solution to any woes. VMS PMDF is available for a distribution fee ($50 last I heard) from Ned Freed (ned@ymir.bitnet) MacPMDF is available from me for a $20 distribution fee. (If you ask I'll tell you more about what it can and can't do. It's not as versatile as VMS PMDF) Jim Kingdon sjk9187@oberlin (bitnet) jkingdon%nomelle.oberlin.edu@vb.cc.cmu.edu (internet)