Archive-Date: Fri, 1 Apr 2005 01:24:29 -0400 Date: Fri, 01 Apr 2005 08:17:26 +0200 From: =?iso-8859-15?Q?Vorl=E4nder=2C_Martin?= Reply-To: Info-TCPware@process.com Subject: Re: tcp/ip software for VMS To: info-tcpware@process.com Message-ID: <336536537175b398c233d2484ae8ce31424ce77d@pdv-systeme.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi, Bob Blum wrote: > There is a hobbyist license out there for=20 > OpenVMS, and many products as well including TCPware and=20 > Multinet TCP/IP from Process Software. (Please, anyone,=20 > correct me on this if I am wrong!) Bob, you're on the point. Relevant URLs: $@Home for OpenVMS Hobbyist Program http://www.openvmshobbyist.com/ (Prerequisite: member of DECUS, Encompass, or whatever it's called today) Process Software - OpenVMS Hobbyist Program http://www.process.com/openvms/hobbyist.html (Prerequisite: a valid VMS license PAK from the Hobbyist program) cu, Martin --=20 | Martin Vorlaender | OpenVMS rules! VMS is today what | work: mv@pdv-systeme.de Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Fri, 1 Apr 2005 06:26:58 -0400 Resent-Date: Fri, 01 Apr 2005 06:20:14 -0500 Date: Thu, 31 Mar 2005 22:44:18 +0100 Resent-From: Geoff Bryant From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: tcp/ip software for VMS Resent-To: info-tcpware@process.com To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Resent-Message-ID: <01LMKITB3I54B09IIG@PROCESS.COM> Message-ID: <424c7d42$1@NEWS.LANGSTOEGER.AT> In article , John Hudak writes: >OK, this NG seems to have some action on it so, my request: I am >looking for a source of CMU-tek for VMS, (any version, hopefully the >most recent) OR, a pointer to another freeware tcp/ip program. Thanks >for your help, Wrong newsgroup. Try vmsnet.networks.tcp-ip.cmu-tek or comp.os.vms But in case you mean free vs. for commerical use, consider TCPware (or Multinet) with the hobbyist license. It might be the better choice... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Fri, 1 Apr 2005 08:03:19 -0400 Date: Fri, 01 Apr 2005 16:58:24 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: tcp/ip software for VMS In-Reply-To: To: info-tcpware@process.com Message-ID: <424D4570.6090701@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit References: Hi ! http://starlet.deltatel.ru/~laishev/cmu-ip/*.* John Hudak wrote: > Hi Folks: > OK, this NG seems to have some action on it so, my request: I am > looking for a source of CMU-tek for VMS, (any version, hopefully the > most recent) OR, a pointer to another freeware tcp/ip program. Thanks > for your help, > > John > > . > -- + WBR, OpenVMS [Sys|Net] HardWorker .................................+ Delta Telecom Inc., IMT-MC-450(CDMA2000) cellular operator Russia,191119,St.Petersburg,Transportny per. 3 Cel: +7 (812) 716-3222 +http://starlet.deltatelecom.ru ............. Frying on OpenVMS only + ================================================================================ Archive-Date: Mon, 11 Apr 2005 09:19:28 -0400 Resent-Date: Mon, 11 Apr 2005 09:18:53 -0400 Date: Mon, 11 Apr 2005 14:38:36 +0100 Resent-From: Geoff Bryant From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: [TCPware] Next version ? Resent-To: info-tcpware@process.com To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Resent-Message-ID: <01LMYNYDC7MQB0BCSE@PROCESS.COM> Message-ID: <425a8bec$1@NEWS.LANGSTOEGER.AT> Now that TCPware V5.6-2 is about 3 years old, did it reach perfection or is there (sometimes/currently) a new version in the works ? What new features ? When will the field test start ? Will there be more common code with Multinet ? With TCPIP ? TIA -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Mon, 11 Apr 2005 09:33:14 -0400 Date: Mon, 11 Apr 2005 09:21:20 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: [TCPware] Next version ? In-Reply-To: "Your message dated Mon, 11 Apr 2005 14:38:36 +0100" <425a8bec$1@NEWS.LANGSTOEGER.AT> To: info-tcpware@process.com CC: bryant@process.com Message-ID: <01LMYOGHT3QSB0CEPP@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii info-tcpware@process.com wrote: > >Now that TCPware V5.6-2 is about 3 years old, did it reach perfection >or is there (sometimes/currently) a new version in the works ? Yes. >What new features ? Off the top of my head, updates to SSH, NTPv4, Itanium support, VMS 8.2 support, NFS ODS-5 support, accumulated bug fixes. >When will the field test start ? It already has. Drop me an email if you're interested. >Will there be more common code with Multinet ? With TCPIP ? NTP. >TIA > >-- >Peter "EPLAN" LANGSTOEGER >Network and OpenVMS system specialist >E-mail peter@langstoeger.at >A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/MultiNet/PMDF/SSH/PreciseMailAntiSpam Engineering Process Software http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 28 Apr 2005 12:20:37 -0400 Date: Thu, 28 Apr 2005 08:12:33 -0700 From: dirf Reply-To: Info-TCPware@process.com Subject: transfing files with TCPware FTP To: info-tcpware@process.com Message-ID: <1114701153.330466.188110@o13g2000cwo.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 I recently installed TCPware FTP and need help getting it configured. I am testing from a Windows client. I can successfully login to the FTP server, but cannot run local commands through the ftp client (such as put, get, etc). I can run remotehelp and run remote commands (such as "quote mkd", "quote cwd" and "quote pwd"). It appears most is working, but when I try to transfer files locally or remotely, the session opens but no data is transmitted. I also do not get any results trying to get a directory listing with dir, ls or "quote retr". what are some starting points to look at for determining if my configuration is correct? Thanks, ================================================================================ Archive-Date: Thu, 28 Apr 2005 12:52:53 -0400 Date: Thu, 28 Apr 2005 12:52:26 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: transfing files with TCPware FTP In-Reply-To: <1114701153.330466.188110@o13g2000cwo.googlegroups.com> To: info-tcpware@process.com Message-ID: <427114CA.9030507@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1114701153.330466.188110@o13g2000cwo.googlegroups.com> dirf wrote: > I recently installed TCPware FTP and need help getting it configured. > I am testing from a Windows client. I can successfully login to the > FTP server, but cannot run local commands through the ftp client (such > as put, get, etc). I can run remotehelp and run remote commands (such > as "quote mkd", "quote cwd" and "quote pwd"). > > It appears most is working, but when I try to transfer files locally or > remotely, the session opens but no data is transmitted. I also do not > get any results trying to get a directory listing with dir, ls or > "quote retr". > > what are some starting points to look at for determining if my > configuration is correct? > Try dong a PASSIVE and then doing an ls or a file transfer. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Thu, 28 Apr 2005 12:53:11 -0400 Date: Thu, 28 Apr 2005 12:52:34 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: transfing files with TCPware FTP In-Reply-To: <1114701153.330466.188110@o13g2000cwo.googlegroups.com> To: info-tcpware@process.com Message-ID: <427114D2.9040900@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1114701153.330466.188110@o13g2000cwo.googlegroups.com> dirf wrote: > I recently installed TCPware FTP and need help getting it configured. > I am testing from a Windows client. I can successfully login to the > FTP server, but cannot run local commands through the ftp client (such > as put, get, etc). I can run remotehelp and run remote commands (such > as "quote mkd", "quote cwd" and "quote pwd"). > > It appears most is working, but when I try to transfer files locally or > remotely, the session opens but no data is transmitted. I also do not > get any results trying to get a directory listing with dir, ls or > "quote retr". > > what are some starting points to look at for determining if my > configuration is correct? > Try doing a PASSIVE and then doing an ls or a file transfer. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Thu, 28 Apr 2005 12:55:36 -0400 Date: Thu, 28 Apr 2005 12:55:15 -0400 From: Mike Bartman Reply-To: Info-TCPware@process.com Subject: RE: transfing files with TCPware FTP To: info-tcpware@process.com Message-ID: <3EF96AF20489A34296050FBD5C36ECB90C6063@beacon.PSC.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > From: dirf [mailto:david.frid@tierserve.com] > It appears most is working, but when I try to transfer files=20 > locally or > remotely, the session opens but no data is transmitted. I also do not > get any results trying to get a directory listing with dir, ls or > "quote retr". >=20 > what are some starting points to look at for determining if my > configuration is correct? First thing I'd check is firewall settings. The FTP protocol involves = you opening a link out to the server for the control channel, but the = data channel is opened by the server back to your system. If you are = behind a firewall that blocks such things, it won't work. If you are using NAT (Network Address Translation) to share a single IP = with several computers behind a router, the router needs to be protocol = aware so it will know which computer to send the incoming link to as = well. Most recent routers that support NAT can do this.=20 -- Mike Bartman Process Software, LLC ================================================================================ Archive-Date: Thu, 28 Apr 2005 13:34:48 -0400 Return-Path: Date: Thu, 28 Apr 2005 13:33:10 -0400 From: neil.rieck@bell.ca Reply-To: Info-TCPware@process.com Subject: Secure FTP ? To: info-tcpware@process.com CC: VMS-SIG@LISTSERV.ENCOMPASSUS.ORG Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Our OpenVMS applications currently make direct calls to either the FTP or TELENET APIs in the TCPware Stack. Can anyone tell me the best method to do an automated "Secure FTP" transfer? (for example, automated FTP's can also be performed using a DCL script along with logical the name FTP_STARTUP. Does SFTP support this type of approach and if so, what logical names would I use?) Neil Rieck Bell-ATS (Advanced Technical Services) Bell Canada 20 Water St. N., Kitchener, Ontario, Canada. N2H-5A5 519-571-6303 ================================================================================ Archive-Date: Thu, 28 Apr 2005 13:43:58 -0400 Date: Thu, 28 Apr 2005 13:43:47 -0400 From: Richard Whalen Reply-To: Info-TCPware@process.com Subject: RE: Secure FTP ? To: info-tcpware@process.com Message-ID: <3EF96AF20489A34296050FBD5C36ECB905A3BC@beacon.PSC.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable SFTP will take a list of commands with the /BATCHFILE qualifier, so you = could create a subprocess to do the SFTP commands. Note that you'll probably have to set up SSH to use public key = authentication. -----Original Message----- From: neil.rieck@bell.ca [mailto:neil.rieck@bell.ca] Sent: Thursday, April 28, 2005 1:33 PM To: info-tcpware@process.com Cc: VMS-SIG@LISTSERV.ENCOMPASSUS.ORG Subject: Secure FTP ? Our OpenVMS applications currently make direct calls to either the FTP or TELENET APIs in the TCPware Stack. Can anyone tell me the best method to do an automated "Secure FTP" transfer? (for example, automated FTP's can also be performed using a DCL script along with logical the name FTP_STARTUP. Does SFTP support this type of approach and if so, what logical names would I use?) Neil Rieck Bell-ATS (Advanced Technical Services) Bell Canada 20 Water St. N., Kitchener, Ontario, Canada. N2H-5A5 519-571-6303 ================================================================================ Archive-Date: Thu, 28 Apr 2005 13:57:25 -0400 Date: Thu, 28 Apr 2005 13:57:09 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: Secure FTP ? In-Reply-To: To: info-tcpware@process.com Message-ID: <427123F5.80404@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: neil.rieck@bell.ca wrote: > Our OpenVMS applications currently make direct calls to either the FTP > or TELENET APIs in the TCPware Stack. > > Can anyone tell me the best method to do an automated "Secure FTP" > transfer? > > (for example, automated FTP's can also be performed using a DCL script > along with logical the name FTP_STARTUP. Does SFTP support this type of > approach and if so, what logical names would I use?) > > You can use the /batchfile to automate SFTP - TCPWARE SFTP2 /BATCHFILE=file Specifies a file with commands to execute. Authentication must be possible without user interaction. -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Fri, 29 Apr 2005 10:48:43 -0400 Resent-Date: Fri, 29 Apr 2005 10:47:21 -0400 Date: Thu, 28 Apr 2005 21:08:21 -0500 Resent-From: Geoff Bryant From: David J Dachtera Subject: Off-the-wall TCPware/Multinet Question Resent-To: info-tcpware@process.com To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Resent-Message-ID: <01LNNW6P28CAB0CMMH@PROCESS.COM> Message-ID: <42719715.929337D@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Y'all need a good laugh? I've been musing over the various problems we've had of late and was wondering if there's any way to combine the various elements of TCPware, Multinet and "UCX" to get the best of all of them. UCX's scalable kernel seems best suited to the environment at work where poorly-designed application software beats the living daylights out of the network. With Multinet, every packet sent is a PHY_IO and thus generates an interrupt. This pushes CPU Utl. and interrupt time through the roof. In both UCX and TCPware, TELNET processes are created by the Job Controller. Thus, TELNET users cannot log in at VMS startup until STDRV has done the initial SET LOGINS/INTERACTIVE command. By contrast, in Multinet, TELNET processes are created by the MUTLINET_SERVER, and logins become possible immediately after Multinet is started, even before the startup process has finished (applications may not be ready for logins, user disks may not be MOUNTed yet, ...). Multinet's printing seems the easiest to manage and understand. By contrast, the very UN*X-ly UCX$PRINTCAP.DAT (TCPIP$PRINTCAP.DAT) method is as bad - or worse - than UN*X. Ideally, I'd like to see the TCP/IP realm of OpenVMS outsourced to Process Software. Realistically, I'd just like to know if there's any way to bring it all together. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Coming soon: Unofficial OpenVMS Marketing Home Page ================================================================================ Archive-Date: Fri, 29 Apr 2005 10:59:19 -0400 Date: Fri, 29 Apr 2005 10:49:58 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: Off-the-wall TCPware/Multinet Question In-Reply-To: "Your message dated Thu, 28 Apr 2005 21:08:21 -0500" <42719715.929337D@comcast.net> To: info-tcpware@process.com CC: bryant@process.com Message-ID: <01LNNWOJIB6CB0CMMH@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii info-tcpware@process.com wrote: > >Y'all need a good laugh? > >I've been musing over the various problems we've had of late and was >wondering if there's any way to combine the various elements of TCPware, >Multinet and "UCX" to get the best of all of them. Well, UCX isn't ours and I won't comment on that. As to merging TCPware and MultiNet, we looked carefully at that when we picked up MultiNet. It's a major project to merge things, taking into account differences and the expectations customers have about how things (many subtle) work. We have in fact combined many things. SSH, SFTP, SMTP, FTP, packet filtering, NTP, Gated, RPC, and probably more (that's off the top of my head) are common now. >UCX's scalable kernel seems best suited to the environment at work where >poorly-designed application software beats the living daylights out of >the network. With Multinet, every packet sent is a PHY_IO and thus >generates an interrupt. This pushes CPU Utl. and interrupt time through >the roof. That's a complicated issue and I'm not sure the right way to look at it. Everyone uses the VMS VCI interface out the bottom, so device interuppts coming in are the same. MultiNet uses direct I/O so that user data is mapped directly into the kernel. TCPware and UCX use buffered I/O which has data copies into system space. Regardless, we look at performance and try to make improvements. We made some improvements for MultiNet 5.0 in a recent kernel eco. >In both UCX and TCPware, TELNET processes are created by the Job >Controller. Thus, TELNET users cannot log in at VMS startup until STDRV >has done the initial SET LOGINS/INTERACTIVE command. By contrast, in >Multinet, TELNET processes are created by the MUTLINET_SERVER, and >logins become possible immediately after Multinet is started, even >before the startup process has finished (applications may not be ready >for logins, user disks may not be MOUNTed yet, ...). > >Multinet's printing seems the easiest to manage and understand. By >contrast, the very UN*X-ly UCX$PRINTCAP.DAT (TCPIP$PRINTCAP.DAT) method >is as bad - or worse - than UN*X. > >Ideally, I'd like to see the TCP/IP realm of OpenVMS outsourced to >Process Software. > >Realistically, I'd just like to know if there's any way to bring it all >together. > >-- >David J Dachtera >dba DJE Systems >http://www.djesys.com/ > >Unofficial OpenVMS Hobbyist Support Page: >http://www.djesys.com/vms/support/ > >Unofficial Affordable OpenVMS Home Page: >http://www.djesys.com/vms/soho/ > >Unofficial OpenVMS-IA32 Home Page: >http://www.djesys.com/vms/ia32/ > >Coming soon: >Unofficial OpenVMS Marketing Home Page ================================================================================ Archive-Date: Fri, 29 Apr 2005 11:55:13 -0400 Date: Fri, 29 Apr 2005 10:53:16 -0500 From: Bob Blum Reply-To: Info-TCPware@process.com Subject: Re: Off-the-wall TCPware/Multinet Question In-Reply-To: <42719715.929337D@comcast.net> To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057413186256FF2_=" This is a multipart message in MIME format. --=_alternative 0057413186256FF2_= Content-Type: text/plain; charset="US-ASCII" Just another good example of the benefits of competing products, even if two thirds of them are currently from the same vendor. But if you want to talk about mix-n-match, the best of all worlds, that sort of thing... Several years back I was running on a VMS system where UCX had been installed, then disabled in favor of an installation of TCPware. (But that's another story...) I had run something (like VMSINSTAL) that goes out and deletes all your symbol definitions, including those for the normal TCPware commands and utilities. A while later I tried to do either an FTP or Telnet. But with the foreign command symbols for TCPware's FTP or Telnet not there, it defaulted back to using the DCL command definition for running FTP or Telnet (using the UCX images). When the commands I was using inside the client acted strange, the online help for what I thought was the TCPware client was for the UCX client instead. I finally realized that my session was running the UCX version of the FTP or Telnet client program through the TCPware UCX emulation! And it worked just fine. Just one more reason why I prefer and recommend TCPware (although I'm getting more experience with Multinet all the time). As was stated in the original posting, though, UCX/TCPIP does have some advantages. And since they ported the Tru64 IP kernel over to VMS when they went to TCPIP v5, it seems a lot more stable. Bob Blum This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. David J Dachtera wrote on 04/28/2005 09:08:21 PM: > Y'all need a good laugh? > > I've been musing over the various problems we've had of late and was > wondering if there's any way to combine the various elements of TCPware, > Multinet and "UCX" to get the best of all of them. > > UCX's scalable kernel seems best suited to the environment at work where > poorly-designed application software beats the living daylights out of > the network. With Multinet, every packet sent is a PHY_IO and thus > generates an interrupt. This pushes CPU Utl. and interrupt time through > the roof. > > In both UCX and TCPware, TELNET processes are created by the Job > Controller. Thus, TELNET users cannot log in at VMS startup until STDRV > has done the initial SET LOGINS/INTERACTIVE command. By contrast, in > Multinet, TELNET processes are created by the MUTLINET_SERVER, and > logins become possible immediately after Multinet is started, even > before the startup process has finished (applications may not be ready > for logins, user disks may not be MOUNTed yet, ...). > > Multinet's printing seems the easiest to manage and understand. By > contrast, the very UN*X-ly UCX$PRINTCAP.DAT (TCPIP$PRINTCAP.DAT) method > is as bad - or worse - than UN*X. > > Ideally, I'd like to see the TCP/IP realm of OpenVMS outsourced to > Process Software. > > Realistically, I'd just like to know if there's any way to bring it all > together. > > -- > David J Dachtera > dba DJE Systems > http://www.djesys.com/ > > Unofficial OpenVMS Hobbyist Support Page: > http://www.djesys.com/vms/support/ > > Unofficial Affordable OpenVMS Home Page: > http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page: > http://www.djesys.com/vms/ia32/ > > Coming soon: > Unofficial OpenVMS Marketing Home Page --=_alternative 0057413186256FF2_= Content-Type: text/html; charset="US-ASCII"
Just another good example of the benefits of competing products, even if two thirds of them are currently from the same vendor.

But if you want to talk about mix-n-match, the best of all worlds, that sort of thing...

Several years back I was running on a VMS system where UCX had been installed, then disabled in favor of an installation of TCPware.  (But that's another story...)  I had run something (like VMSINSTAL) that goes out and deletes all your symbol definitions, including those for the normal TCPware commands and utilities.

A while later I tried to do either an FTP or Telnet.  But with the foreign command symbols for TCPware's FTP or Telnet not there, it defaulted back to using the DCL command definition for running FTP or Telnet (using the UCX images).  When the commands I was using inside the client acted strange, the online help for what I thought was the TCPware client was for the UCX client instead.  I finally realized that my session was running the UCX version of the FTP or Telnet client program through the TCPware UCX emulation!  And it worked just fine.

Just one more reason why I prefer and recommend TCPware (although I'm getting more experience with Multinet all the time).

As was stated in the original posting, though, UCX/TCPIP does have some advantages.  And since they ported the Tru64 IP kernel over to VMS when they went to TCPIP v5, it seems a lot more stable.

Bob Blum
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED.  If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

David J Dachtera <djesys.nospam@comcast.net> wrote on 04/28/2005 09:08:21 PM:

> Y'all need a good laugh?
>
> I've been musing over the various problems we've had of late and was
> wondering if there's any way to combine the various elements of TCPware,
> Multinet and "UCX" to get the best of all of them.
>
> UCX's scalable kernel seems best suited to the environment at work where
> poorly-designed application software beats the living daylights out of
> the network. With Multinet, every packet sent is a PHY_IO and thus
> generates an interrupt. This pushes CPU Utl. and interrupt time through
> the roof.
>
> In both UCX and TCPware, TELNET processes are created by the Job
> Controller. Thus, TELNET users cannot log in at VMS startup until STDRV
> has done the initial SET LOGINS/INTERACTIVE command. By contrast, in
> Multinet, TELNET processes are created by the MUTLINET_SERVER, and
> logins become possible immediately after Multinet is started, even
> before the startup process has finished (applications may not be ready
> for logins, user disks may not be MOUNTed yet, ...).
>
> Multinet's printing seems the easiest to manage and understand. By
> contrast, the very UN*X-ly UCX$PRINTCAP.DAT (TCPIP$PRINTCAP.DAT) method
> is as bad - or worse - than UN*X.
>
> Ideally, I'd like to see the TCP/IP realm of OpenVMS outsourced to
> Process Software.
>
> Realistically, I'd just like to know if there's any way to bring it all
> together.
>
> --
> David J Dachtera
> dba DJE Systems
> http://www.djesys.com/
>
> Unofficial OpenVMS Hobbyist Support Page:
> http://www.djesys.com/vms/support/
>
> Unofficial Affordable OpenVMS Home Page:
> http://www.djesys.com/vms/soho/
>
> Unofficial OpenVMS-IA32 Home Page:
> http://www.djesys.com/vms/ia32/
>
> Coming soon:
> Unofficial OpenVMS Marketing Home Page
 --=_alternative 0057413186256FF2_=-- ================================================================================ Archive-Date: Sat, 30 Apr 2005 01:03:26 -0400 Resent-Date: Sat, 30 Apr 2005 01:01:51 -0400 Date: Fri, 29 Apr 2005 22:08:16 -0500 Resent-From: Geoff Bryant From: David J Dachtera Subject: Re: Off-the-wall TCPware/Multinet Question Resent-To: info-tcpware@process.com To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Resent-Message-ID: <01LNOQ5NJ8H4BESCQC@PROCESS.COM> Message-ID: <4272F6A0.1079FA90@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Bob Blum wrote: Hi, Bob, Can I ask two favors? 1. Please don't top-post. 2. Please turn off MIME. I had to begin the reply just read your message. It showed up in my newsreader (Netscape V4.77) in such a small font, I couldn't read it even with my glasses on. > > snip > > As was stated in the original posting, though, UCX/TCPIP does have > some advantages. And since they ported the Tru64 IP kernel over to > VMS when they went to TCPIP v5, it seems a lot more stable. Well, the key feature I seem to need at work is for network I/O to be done via buffered I/O rather than Direct I/O. We have one real abomination of an application that not only floods the network, it peaks out the CPUs with interrupt service as a result (we run Multinet - V5.0 died a miserable death and took the cluster with it; V4.4A is livable, but ...). The single source library for Tru65 and VMS seems a moot point at this stage since Tru64 is doomed to become extinct along with Alpha. TCPware at least began life in the DEC world. I'm told that UCX's heritage is 4.xBSD as is Multinet's, but dunno for sure. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Coming soon: Unofficial OpenVMS Marketing Home Page ================================================================================ Archive-Date: Sat, 30 Apr 2005 13:11:07 -0400 Date: Sat, 30 Apr 2005 11:08:56 -0600 From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: Off-the-wall TCPware/Multinet Question In-Reply-To: <4272F6A0.1079FA90@comcast.net> To: info-tcpware@process.com Message-ID: <6.2.0.14.0.20050430110829.02481eb0@sys6.mehlhop.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii References: <4272F6A0.1079FA90@comcast.net> At 09:08 PM 4/29/2005, you wrote: >Bob Blum wrote: > >Hi, Bob, > >Can I ask two favors? > > 1. Please don't top-post. > 2. Please turn off MIME. I had to begin the reply just read your >message. It showed up in my newsreader (Netscape V4.77) in such a small >font, I couldn't read it even with my glasses on. > > > > snip > > > > As was stated in the original posting, though, UCX/TCPIP does have > > some advantages. And since they ported the Tru64 IP kernel over to > > VMS when they went to TCPIP v5, it seems a lot more stable. > >Well, the key feature I seem to need at work is for network I/O to be >done via buffered I/O rather than Direct I/O. We have one real >abomination of an application that not only floods the network, it peaks >out the CPUs with interrupt service as a result (we run Multinet - V5.0 >died a miserable death and took the cluster with it; V4.4A is livable, >but ...). Was that WITH the latest UCXDRIVER and Kernel Updates???? >The single source library for Tru65 and VMS seems a moot point at this >stage since Tru64 is doomed to become extinct along with Alpha. TCPware >at least began life in the DEC world. I'm told that UCX's heritage is >4.xBSD as is Multinet's, but dunno for sure. > >-- >David J Dachtera >dba DJE Systems >http://www.djesys.com/ > >Unofficial OpenVMS Hobbyist Support Page: >http://www.djesys.com/vms/support/ > >Unofficial Affordable OpenVMS Home Page: >http://www.djesys.com/vms/soho/ > >Unofficial OpenVMS-IA32 Home Page: >http://www.djesys.com/vms/ia32/ > >Coming soon: >Unofficial OpenVMS Marketing Home Page Jim Mehlhop Join Cauce to outlaw spam http://www.cauce.org/