Archive-Date: Fri, 2 Feb 2001 12:00:46 -0400 Date: Fri, 02 Feb 2001 12:02:44 -0500 From: Alan Neighbors Reply-To: Info-TCPware@process.com Subject: FTP Byte Limit Problem... X-MX-Warning: Warning -- Invalid "To" header. To: <> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, We are encountering a problem FTPing files from a UNIX box to an=20 OpenVMS Alpha system. When ever we try to send a file, that is greater=20 than 8193 bytes, we get this error: 552 %TCPWARE-E-IVDATATYPE, invalid data type for file or=20 file corrupted, ... What is causing this and what do I need to do to fix this problem??? Thanks! Alan Alan J. Neighbors LabCorp - Systems Technologies Group (615)221-1924 Internal Email: neighba.nas01.nassec External Email: aneighbors@labcorp.com "Whoso would be a man, must be a nonconformist." - Ralph Waldo Emerson ================================================================================ Archive-Date: Fri, 2 Feb 2001 12:06:12 -0400 Date: Fri, 02 Feb 2001 12:05:01 -0500 From: Richard Whalen Reply-To: Info-TCPware@process.com Subject: RE: FTP Byte Limit Problem... To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE860381E64D@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 DEFINE TCPWARE_FTP_MAXREC to be larger than the largest record you expect. The default value for this is 8192 and it is designed to catch transfers that might be erroneous. -----Original Message----- From: Alan Neighbors [mailto:aneighbors@labcorp.com] Sent: Friday, February 02, 2001 12:03 PM To: < Subject: FTP Byte Limit Problem... Hello, We are encountering a problem FTPing files from a UNIX box to an OpenVMS Alpha system. When ever we try to send a file, that is greater than 8193 bytes, we get this error: 552 %TCPWARE-E-IVDATATYPE, invalid data type for file or file corrupted, ... What is causing this and what do I need to do to fix this problem??? Thanks! Alan Alan J. Neighbors LabCorp - Systems Technologies Group (615)221-1924 Internal Email: neighba.nas01.nassec External Email: aneighbors@labcorp.com "Whoso would be a man, must be a nonconformist." - Ralph Waldo Emerson ================================================================================ Archive-Date: Fri, 2 Feb 2001 12:09:07 -0400 Date: Fri, 02 Feb 2001 10:02:39 -0700 From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: FTP Byte Limit Problem... In-Reply-To: To: info-tcpware@process.com Message-ID: <5.0.2.1.2.20010202100146.01d968e0@mehlhop.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii What version of TCPware and what commands are being issued from the Unix box. Also what kind of a file is it? At 12:02 PM 2/2/01 -0500, you wrote: >Hello, > >We are encountering a problem FTPing files from a UNIX box to an >OpenVMS Alpha system. When ever we try to send a file, that is greater >than 8193 bytes, we get this error: > >552 %TCPWARE-E-IVDATATYPE, invalid data type for file or >file corrupted, ... > >What is causing this and what do I need to do to fix this problem??? > >Thanks! >Alan > >Alan J. Neighbors >LabCorp - Systems Technologies Group >(615)221-1924 >Internal Email: neighba.nas01.nassec >External Email: aneighbors@labcorp.com > >"Whoso would be a man, must be a nonconformist." - Ralph Waldo Emerson _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Fri, 2 Feb 2001 12:25:43 -0400 Date: Fri, 02 Feb 2001 12:27:38 -0500 From: Alan Neighbors Reply-To: Info-TCPware@process.com Subject: RE: FTP Byte Limit Problem... To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Worked like a Champ! Thanks!!! >>> whalenr@process.com 2/2/01 11:05:01 AM >>> DEFINE TCPWARE_FTP_MAXREC to be larger than the largest record you expect. The default value for this is 8192 and it is designed to catch transfers that might be erroneous. -----Original Message----- From: Alan Neighbors [mailto:aneighbors@labcorp.com]=20 Sent: Friday, February 02, 2001 12:03 PM To: < Subject: FTP Byte Limit Problem... Hello, We are encountering a problem FTPing files from a UNIX box to an=20 OpenVMS Alpha system. When ever we try to send a file, that is greater=20 than 8193 bytes, we get this error: 552 %TCPWARE-E-IVDATATYPE, invalid data type for file or=20 file corrupted, ... What is causing this and what do I need to do to fix this problem??? Thanks! Alan Alan J. Neighbors LabCorp - Systems Technologies Group (615)221-1924 Internal Email: neighba.nas01.nassec External Email: aneighbors@labcorp.com=20 "Whoso would be a man, must be a nonconformist." - Ralph Waldo Emerson ================================================================================ Archive-Date: Fri, 2 Feb 2001 19:46:01 -0400 Date: Fri, 02 Feb 2001 19:38:11 +0000 From: Laurence Childs Reply-To: Info-TCPware@process.com Subject: TCPWare LPD & NT To: info-tcpware@process.com Message-ID: Hi I am in the process of setting up an NT server and NT domain and would like to make accessible to these windows users printers which are set up on the VAX/VMS. Has anybody attempted this ?? if so were you successful and can you give me any pointers and pitfalls to avoid cheers Laurence ================================================================================ Archive-Date: Mon, 5 Feb 2001 17:40:23 -0400 Date: Mon, 05 Feb 2001 20:25:34 +0000 (GMT) From: gessling@my-deja.com Reply-To: Info-TCPware@process.com Subject: What is the maximum number of BG: devices? To: info-tcpware@process.com Message-ID: <95n27h$euq$1@nnrp1.deja.com> Hi, VAX/VMS 5.5-2H4, TCPware 5.3-2 I am trying to troubleshoot my application, it is written for UCX, and I am a TCPWARE novice. I have a sporadic problem with the program getting "%SYSTEM-F-NONETMBX, operation requires NETMBX privilege" (%X28a4) returned from assigning a channel to the BG: device. Since the process has NETMBX privilege, I think that I am running into a limit on the number of BG devices. Is there a limit? How can I tell what the limit is? If there is a limit, how can I make it larger? I have had similar problems with the default maximum number of sockets in UCX, which is why I suspect the same thing is happening with TCPware. Thanks in advance, Paul Gessling Sent via Deja.com http://www.deja.com/ ================================================================================ Archive-Date: Mon, 5 Feb 2001 18:15:08 -0400 Date: Mon, 05 Feb 2001 16:08:23 -0700 From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: What is the maximum number of BG: devices? In-Reply-To: <95n27h$euq$1@nnrp1.deja.com> To: info-tcpware@process.com Message-ID: <5.0.2.1.2.20010205160741.098511b0@mehlhop.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii At 08:25 PM 2/5/01 +0000, you wrote: >Hi, > >VAX/VMS 5.5-2H4, TCPware 5.3-2 > >I am trying to troubleshoot my application, it is written for UCX, and >I am a TCPWARE novice. > >I have a sporadic problem with the program getting "%SYSTEM-F-NONETMBX, >operation requires NETMBX privilege" (%X28a4) returned from >assigning a channel to the BG: device. > >Since the process has NETMBX privilege, I think that I am running into >a limit on the number of BG devices. Is there a limit? How can I tell >what the limit is? If there is a limit, how can I make it larger? The limit is the VMS limit of 10000 (0-9999) Jim >I have had similar problems with the default maximum number of sockets >in UCX, which is why I suspect the same thing is happening with TCPware. > >Thanks in advance, > >Paul Gessling > > >Sent via Deja.com >http://www.deja.com/ _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Tue, 6 Feb 2001 12:07:04 -0400 Date: Tue, 06 Feb 2001 16:50:51 +0000 (GMT) From: gessling@my-deja.com Reply-To: Info-TCPware@process.com Subject: Re: What is the maximum number of BG: devices? To: info-tcpware@process.com Message-ID: <95pa16$bt1$1@nnrp1.deja.com> Hi, To be more specific, is there a limit to the total number of sockets in TCPware? If there is no limit to the total number of sockets, and my application only occasionally gets the error below, is there any other reason that assigning a channel to BG: would get the error? Thanks again in advance, Paul. In article <5.0.2.1.2.20010205160741.098511b0@mehlhop.org>, Jim Mehlhop wrote: > At 08:25 PM 2/5/01 +0000, you wrote: > >Hi, > > > >VAX/VMS 5.5-2H4, TCPware 5.3-2 > > > >I am trying to troubleshoot my application, it is written for UCX, and > >I am a TCPWARE novice. > > > >I have a sporadic problem with the program getting "%SYSTEM-F- NONETMBX, > >operation requires NETMBX privilege" (%X28a4) returned from > >assigning a channel to the BG: device. > > > >Since the process has NETMBX privilege, I think that I am running into > >a limit on the number of BG devices. Is there a limit? How can I tell > >what the limit is? If there is a limit, how can I make it larger? > > The limit is the VMS limit of 10000 (0-9999) > Jim > > >I have had similar problems with the default maximum number of sockets > >in UCX, which is why I suspect the same thing is happening with TCPware. > > > >Thanks in advance, > > > >Paul Gessling > > > > > >Sent via Deja.com > >http://www.deja.com/ > > ________________________________________________________________________ _ > Jim Mehlhop, Support Engineer > Process Software > Mehlhop@process.com > Phone 719-638-8448 > Join Cauce to outlaw spam > http://www.cauce.org/ > ________________________________________________________________________ _ > > Sent via Deja.com http://www.deja.com/ ================================================================================ Archive-Date: Wed, 7 Feb 2001 17:09:34 -0400 Date: Wed, 07 Feb 2001 17:08:19 -0500 (EST) From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: What is the maximum number of BG: devices? To: info-tcpware@process.com Message-ID: <01JZU448XXD29PLTB0@ALCOR.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sockets in TCPware will have an associated VMS device (INET, BG, TCP, IP, or UDP). The VMS limit of 10,000 devices (0 - 9999 and 0 is the template so it doesn't really count) limits how many of each of these you can have. Underneath these devices, there is nothing limiting things except at some point useage of non-paged pool. What you might want to check is the SYSGEN parameter CHANNELCNT or the authorize parameter FILLM. On Tue, 06 Feb 2001 16:50:51 +0000 (GMT), gessling@my-deja.com wrote: > >Hi, > >To be more specific, is there a limit to the total number of sockets in >TCPware? > >If there is no limit to the total number of sockets, and my application >only occasionally gets the error below, is there any other reason that >assigning a channel to BG: would get the error? > >Thanks again in advance, >Paul. > >In article <5.0.2.1.2.20010205160741.098511b0@mehlhop.org>, > Jim Mehlhop wrote: >> At 08:25 PM 2/5/01 +0000, you wrote: >> >Hi, >> > >> >VAX/VMS 5.5-2H4, TCPware 5.3-2 >> > >> >I am trying to troubleshoot my application, it is written for UCX, >and >> >I am a TCPWARE novice. >> > >> >I have a sporadic problem with the program getting "%SYSTEM-F- >NONETMBX, >> >operation requires NETMBX privilege" (%X28a4) returned from >> >assigning a channel to the BG: device. >> > >> >Since the process has NETMBX privilege, I think that I am running >into >> >a limit on the number of BG devices. Is there a limit? How can I tell >> >what the limit is? If there is a limit, how can I make it larger? >> >> The limit is the VMS limit of 10000 (0-9999) >> Jim >> >> >I have had similar problems with the default maximum number of >sockets >> >in UCX, which is why I suspect the same thing is happening with >TCPware. >> > >> >Thanks in advance, >> > >> >Paul Gessling >> > >> > >> >Sent via Deja.com >> >http://www.deja.com/ >> >> >________________________________________________________________________ >_ >> Jim Mehlhop, Support Engineer >> Process Software >> Mehlhop@process.com >> Phone 719-638-8448 >> Join Cauce to outlaw spam >> http://www.cauce.org/ >> >________________________________________________________________________ >_ >> >> > > >Sent via Deja.com >http://www.deja.com/ ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/MultiNet/PMDF Engineering Process Software http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Wed, 7 Feb 2001 17:36:35 -0400 Date: Wed, 07 Feb 2001 15:29:46 -0700 From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: What is the maximum number of BG: devices? In-Reply-To: <01JZU448XXD29PLTB0@ALCOR.PROCESS.COM> To: info-tcpware@process.com Message-ID: <5.0.2.1.2.20010207152916.01b70ec0@mehlhop.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Also make sure the following ECO is installed ftp://ftp.process.com/support/54_3/netcp_v543p010.zip > > >NETCP Patch kit revision 1.0 for TCPware version 5.4-3 20-Jun-2000 > >Copyright (c) 2000, by Process Software Corporation > > This VMSinstallable saveset provides new versions of > NETCP.EXE for TCPware for OpenVMS. > > This patch is applicable to TCPware version 5.3-2 and 5.4-3 and all > supported versions of OpenVMS. > > This patch corrects a problem in NETCP that can cause BG devices to > be left on the system after the process using them has gone away. >(DE 5962) > Rank 3 > > The old version of TCPWARE:NETCP.EXE will be > renamed to TCPWARE:NETCP.EXE_OLD > Once installed, you may undo this patch by renaming the file back to > TCPWARE:NETCP.EXE > > NOTE: You do not need to reboot but you must start or restart > At 05:08 PM 2/7/01 -0500, you wrote: >Sockets in TCPware will have an associated VMS device (INET, BG, TCP, IP, or >UDP). The VMS limit of 10,000 devices (0 - 9999 and 0 is the template so it >doesn't really count) limits how many of each of these you can have. >Underneath these devices, there is nothing limiting things except at some >point >useage of non-paged pool. > >What you might want to check is the SYSGEN parameter CHANNELCNT or the >authorize parameter FILLM. > >On Tue, 06 Feb 2001 16:50:51 +0000 (GMT), gessling@my-deja.com wrote: > > > >Hi, > > > >To be more specific, is there a limit to the total number of sockets in > >TCPware? > > > >If there is no limit to the total number of sockets, and my application > >only occasionally gets the error below, is there any other reason that > >assigning a channel to BG: would get the error? > > > >Thanks again in advance, > >Paul. > > > >In article <5.0.2.1.2.20010205160741.098511b0@mehlhop.org>, > > Jim Mehlhop wrote: > >> At 08:25 PM 2/5/01 +0000, you wrote: > >> >Hi, > >> > > >> >VAX/VMS 5.5-2H4, TCPware 5.3-2 > >> > > >> >I am trying to troubleshoot my application, it is written for UCX, > >and > >> >I am a TCPWARE novice. > >> > > >> >I have a sporadic problem with the program getting "%SYSTEM-F- > >NONETMBX, > >> >operation requires NETMBX privilege" (%X28a4) returned from > >> >assigning a channel to the BG: device. > >> > > >> >Since the process has NETMBX privilege, I think that I am running > >into > >> >a limit on the number of BG devices. Is there a limit? How can I tell > >> >what the limit is? If there is a limit, how can I make it larger? > >> > >> The limit is the VMS limit of 10000 (0-9999) > >> Jim > >> > >> >I have had similar problems with the default maximum number of > >sockets > >> >in UCX, which is why I suspect the same thing is happening with > >TCPware. > >> > > >> >Thanks in advance, > >> > > >> >Paul Gessling > >> > > >> > > >> >Sent via Deja.com > >> >http://www.deja.com/ > >> > >> > >________________________________________________________________________ > >_ > >> Jim Mehlhop, Support Engineer > >> Process Software > >> Mehlhop@process.com > >> Phone 719-638-8448 > >> Join Cauce to outlaw spam > >> http://www.cauce.org/ > >> > >________________________________________________________________________ > >_ > >> > >> > > > > > >Sent via Deja.com > >http://www.deja.com/ > >------------------------------------------------------------- >Geoff Bryant bryant@process.com >TCPware/MultiNet/PMDF Engineering >Process Software http://www.process.com/ >959 Concord St. >Framingham, MA 01701 USA _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Thu, 8 Feb 2001 06:23:14 -0400 Date: Thu, 08 Feb 2001 14:04:26 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: IPv6 To: info-tcpware@process.com Message-ID: <3A827D3A.6CEDE0AE@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi All! What is answer from PSC about of IPv6? -------------------- TCP/IP for OpenVMS engineering is pleased to announce that TCP/IP Services 5.1 now support Ipv6. Therefore we will no longer provide a separate IPv6 Early Adopters Kit (EAK). Best regards, Yanick Pouffary TCP/IP for OpenVMS engineering --------------------- -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom Inc, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Thu, 8 Feb 2001 18:11:11 -0400 Date: Thu, 08 Feb 2001 17:00:41 -0600 (CST) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: IPv6 In-Reply-To: "Your message dated Thu, 08 Feb 2001 14:04:26 +0300" <3A827D3A.6CEDE0AE@SMTP.DeltaTel.RU> To: info-tcpware@process.com Message-ID: <01JZVIL33Z9E8WVYKD@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Ruslan wrote: > > What is answer from PSC about of IPv6? > Here's what I posted to Info-MultiNet in September 1999: We have been monitoring the IPv6 developments, and continue to do so. At this point, we have no concrete timeframe for IPv6 support. We have had a prototype kernel with IPv6 support for quite some time now (it was tested at Connectathon in Spring 1998), but given the total lack of interest from customers (and the world at large), we have not included IPv6 support in either product yet. That's still true. Based on customer surveys, our customers are not really interested in IPv6 yet. Aside from people wanting to play with it, no one seems really interested in it, and it won't become an issue until all of the router companies are offering full support for IPv6. We will continue to monitor the world's readiness for IPv6, but we have no firm timeframe for IPv6 support yet. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Fri, 9 Feb 2001 03:44:58 -0400 Date: Fri, 09 Feb 2001 11:26:07 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: IPv6 To: info-tcpware@process.com Message-ID: <3A83A99F.8CA665E1@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi Hunter! There is a number of application developers which want to be ready for time when IPv6 will start. So, the only TCP/IP 5.1 will give us an ability to get a work environment for testing and developing an applications. Thanks, Hunter. Hunter Goatley wrote: > > Ruslan wrote: > > > > What is answer from PSC about of IPv6? > > > Here's what I posted to Info-MultiNet in September 1999: > > We have been monitoring the IPv6 developments, and continue to do so. > At this point, we have no concrete timeframe for IPv6 support. We > have had a prototype kernel with IPv6 support for quite some time > now (it was tested at Connectathon in Spring 1998), but given the > total lack of interest from customers (and the world at large), we > have not included IPv6 support in either product yet. > > That's still true. Based on customer surveys, our customers are not > really interested in IPv6 yet. Aside from people wanting to play with > it, no one seems really interested in it, and it won't become an issue > until all of the router companies are offering full support for IPv6. > > We will continue to monitor the world's readiness for IPv6, but we > have no firm timeframe for IPv6 support yet. > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www.goatley.com/hunter/ -- Cheers. +---------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222 ================================================================================ Archive-Date: Fri, 9 Feb 2001 07:34:55 -0400 Date: Fri, 09 Feb 2001 06:28:22 -0600 (CST) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: IPv6 In-Reply-To: "Your message dated Fri, 09 Feb 2001 11:26:07 +0300" <3A83A99F.8CA665E1@SMTP.DeltaTel.RU> To: info-tcpware@process.com Message-ID: <01JZWANT1HLK8WVYKD@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Info-TCPware@process.com wrote: > >Hi Hunter! > Hi, Ruslan. >There is a number of application developers which want to be ready for >time when IPv6 will start. So, the only TCP/IP 5.1 will give us an >ability to get a work environment for testing and developing an >applications. > Personally, I think it's still very optimistic to think IPv6 will be largely deployed in the next half-dozen years. It was once needed; since then, people keep coming up with ways (CIDR, NAT) to put off the need for IPv6. So far, our customers have agreed, so we've put our efforts into things like SSH and IPP that customers are asking for today, rather than spending a lot of time on something that might still be years away from deployment. I can appreciate your interest, and we haven't forgotten IPv6, it just hasn't been our biggest priority yet because it's not a priority for most of our customers. That could change soon, but that's where it sits at the moment. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Fri, 9 Feb 2001 10:06:27 -0400 Date: Fri, 09 Feb 2001 17:48:57 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: IPv6 To: info-tcpware@process.com Message-ID: <3A840359.33E4C62E@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Thanks Hunter. Hunter Goatley wrote: > > Info-TCPware@process.com wrote: > > > >Hi Hunter! > > > Hi, Ruslan. > > >There is a number of application developers which want to be ready for > >time when IPv6 will start. So, the only TCP/IP 5.1 will give us an > >ability to get a work environment for testing and developing an > >applications. > > > Personally, I think it's still very optimistic to think IPv6 will be > largely deployed in the next half-dozen years. It was once needed; > since then, people keep coming up with ways (CIDR, NAT) to put off the > need for IPv6. > > So far, our customers have agreed, so we've put our efforts into > things like SSH and IPP that customers are asking for today, rather > than spending a lot of time on something that might still be years > away from deployment. > > I can appreciate your interest, and we haven't forgotten IPv6, it just > hasn't been our biggest priority yet because it's not a priority for > most of our customers. That could change soon, but that's where it > sits at the moment. > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www.goatley.com/hunter/ -- Cheers. +---------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222 ================================================================================ Archive-Date: Sat, 10 Feb 2001 09:42:27 -0400 Date: Sat, 10 Feb 2001 17:26:11 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: DCE 1.5 & TCPWare To: info-tcpware@process.com Message-ID: <3A854F83.1C9AB5E7@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi All! Just for you information: the way is described in the documentation "Compaq DCE for OpenVMS VAX and OpenVMS Alpha Release Notes"/"10 Using TCPware with DCE" is not work at all. Be advised. -- Cheers. +---------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222 ================================================================================ Archive-Date: Tue, 13 Feb 2001 15:11:54 -0400 Date: Tue, 13 Feb 2001 20:59:02 +0100 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: [TCPware V5.4-3] still problems with FTP clients To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a899206$1@news.kapsch.co.at> I just wanted to let you know, that I have still problems with my TCPware V5.4-3 FTP clients (FTP.EXE and DECW_FTP.EXE on Alpha OpenVMS V7.2-1) here. I installed MGFTP to be sure, that not VMS or the IP stack is the problem. And indeed the MGFTP client works without problems. Downloading from ftp.service.digital.com, ftp.madgoat.com, ftp.process.com,... all failed at about the time when the transfer is finished. That means I download for a couple of minutes (and a lot of lines of #) and then I get %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection -SYSTEM-F-VCBROKEN, virtual circuit broken So far, I haven't seen a difference in using MGET vs GET or normal vs passive. But I think, the problem is related to the size of the downloaded files... Anybody else seeing this problem ? Any ideas ? -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 13 Feb 2001 15:29:52 -0400 Date: Tue, 13 Feb 2001 15:28:19 -0500 From: Richard Whalen Reply-To: Info-TCPware@process.com Subject: RE: [TCPware V5.4-3] still problems with FTP clients To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE860381E6A7@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Since this problem happens with larger files (which presumably would take longer), I would guess that the firewall is dropping what it believes to be an inactive connection (the control connection). Make sure that TCPWARE is NOT being started /NOKEEPALIVE (chapter 7-2 in the management guide), as keepalives will help in persuading the firewall to keep the connection open. Also look at the parameters of the firewall for when it drops inactive connections. -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: Tuesday, February 13, 2001 2:59 PM To: info-tcpware@process.com Subject: [TCPware V5.4-3] still problems with FTP clients I just wanted to let you know, that I have still problems with my TCPware V5.4-3 FTP clients (FTP.EXE and DECW_FTP.EXE on Alpha OpenVMS V7.2-1) here. I installed MGFTP to be sure, that not VMS or the IP stack is the problem. And indeed the MGFTP client works without problems. Downloading from ftp.service.digital.com, ftp.madgoat.com, ftp.process.com,... all failed at about the time when the transfer is finished. That means I download for a couple of minutes (and a lot of lines of #) and then I get %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection -SYSTEM-F-VCBROKEN, virtual circuit broken So far, I haven't seen a difference in using MGET vs GET or normal vs passive. But I think, the problem is related to the size of the downloaded files... Anybody else seeing this problem ? Any ideas ? -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 13 Feb 2001 16:16:03 -0400 Date: Tue, 13 Feb 2001 16:13:12 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: RE: [TCPware V5.4-3] still problems with FTP clients]] To: info-tcpware@process.com Message-ID: <3A89A368.24F9CAC8@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > I just wanted to let you know, that I have still problems with my TCPware > V5.4-3 FTP clients (FTP.EXE and DECW_FTP.EXE on Alpha OpenVMS V7.2-1) here. > > I installed MGFTP to be sure, that not VMS or the IP stack is the problem. > And indeed the MGFTP client works without problems. > > Downloading from ftp.service.digital.com, ftp.madgoat.com, ftp.process.com,... > all failed at about the time when the transfer is finished. That means I > download for a couple of minutes (and a lot of lines of #) and then I get > > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection > -SYSTEM-F-VCBROKEN, virtual circuit broken > > So far, I haven't seen a difference in using MGET vs GET or normal vs passive. > But I think, the problem is related to the size of the downloaded files... > > Anybody else seeing this problem ? > Any ideas ? > Peter, I have seen this problem at a couple of sites. From the TCPDUMPS the other customers sent the problem appeared to be that TCPware was sending a keep-alive on the control connection and was receiving a RST in response. What was odd was that even though the remote side had reset the control connection, after the data was sent and the data connection was closed the remote side was sending the "2XX transfer complete" message on the control connection. Since it had previously reset the control connection this made no sense and leads me to believe that this is caused by some outside source, i.e. a router, or NAT box. One site fixed it but couldn't get any info on what the network folks did to fix it. The other site I'm still waiting to hear back from. I'll post more here when/if I do hear back from them. In the mean time if you could capture a TCPDUMP of this happening I can see if your problem looks the same. Use the following TCPDUMP command - $ NETCU TCPDUMP/SNAP=128/OUT=TCPDUMP.BIN HOST 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: Tue, 13 Feb 2001 16:26:38 -0400 Sender: goatley@triton.process.com Date: Tue, 13 Feb 2001 16:17:05 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: RE: [TCPware V5.4-3] still problems with FTP clients]] To: info-tcpware@process.com Message-ID: <3A89A451.EC016EEA@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > I just wanted to let you know, that I have still problems with my TCPware > V5.4-3 FTP clients (FTP.EXE and DECW_FTP.EXE on Alpha OpenVMS V7.2-1) here. > > I installed MGFTP to be sure, that not VMS or the IP stack is the problem. > And indeed the MGFTP client works without problems. > > Downloading from ftp.service.digital.com, ftp.madgoat.com, ftp.process.com,... > all failed at about the time when the transfer is finished. That means I > download for a couple of minutes (and a lot of lines of #) and then I get > > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection > -SYSTEM-F-VCBROKEN, virtual circuit broken > > So far, I haven't seen a difference in using MGET vs GET or normal vs passive. > But I think, the problem is related to the size of the downloaded files... > > Anybody else seeing this problem ? > Any ideas ? > Peter, I have seen this problem at a couple of sites. From the TCPDUMPS the other customers sent the problem appeared to be that TCPware was sending a keep-alive on the control connection and was receiving a RST in response. What was odd was that even though the remote side had reset the control connection, after the data was sent and the data connection was closed the remote side was sending the "2XX transfer complete" message on the control connection. Since it had previously reset the control connection this made no sense and leads me to believe that this is caused by some outside source, i.e. a router, or NAT box. One site fixed it but couldn't get any info on what the network folks did to fix it. The other site I'm still waiting to hear back from. I'll post more here when/if I do hear back from them. In the mean time if you could capture a TCPDUMP of this happening I can see if your problem looks the same. Use the following TCPDUMP command - $ NETCU TCPDUMP/SNAP=128/OUT=TCPDUMP.BIN HOST 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: Tue, 13 Feb 2001 23:40:47 -0400 Date: Wed, 14 Feb 2001 03:47:58 +0100 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: [TCPware V5.4-3] still problems with FTP clients To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a89f1de.524144494f47414741@radiogaga.harz.de> Richard Whalen (whalenr@process.com) wrote: > Peter "EPLAN" LANGSTOEGER wrote: > > all failed at about the time when the transfer is finished. That means I > > download for a couple of minutes (and a lot of lines of #) and then I get > > > > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection > > -SYSTEM-F-VCBROKEN, virtual circuit broken > > Since this problem happens with larger files (which presumably would take > longer), I would guess that the firewall is dropping what it believes to be > an inactive connection (the control connection). Make sure that TCPWARE is > NOT being started /NOKEEPALIVE (chapter 7-2 in the management guide), as > keepalives will help in persuading the firewall to keep the connection open. > Also look at the parameters of the firewall for when it drops inactive > connections. I just had a support case (5.3-3, two firewalls, UCX server on the other side) with that error message on my desk. Process support helped me out (by analyzing a TCP dump of the connection) which showed that one of the firewalls responded to a keepalive packet with a RESET. So, you could as well try and start TCPware with /NOKEEPALIVE... cu, Martin ================================================================================ Archive-Date: Wed, 14 Feb 2001 10:38:44 -0400 Date: Wed, 14 Feb 2001 16:16:06 +0100 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: [TCPware V5.4-3] still problems with FTP clients To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a8aa136$1@news.kapsch.co.at> In article <3a89f1de.524144494f47414741@radiogaga.harz.de>, martin@radiogaga.harz.de (Martin Vorlaender) writes: >Richard Whalen (whalenr@process.com) wrote: >> Peter "EPLAN" LANGSTOEGER wrote: >> > all failed at about the time when the transfer is finished. That means I >> > download for a couple of minutes (and a lot of lines of #) and then I get >> > >> > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection >> > -SYSTEM-F-VCBROKEN, virtual circuit broken >> >> Since this problem happens with larger files (which presumably would take >> longer), I would guess that the firewall is dropping what it believes to be >> an inactive connection (the control connection). Make sure that TCPWARE is >> NOT being started /NOKEEPALIVE (chapter 7-2 in the management guide), as >> keepalives will help in persuading the firewall to keep the connection open. >> Also look at the parameters of the firewall for when it drops inactive >> connections. > >I just had a support case (5.3-3, two firewalls, UCX server on the other >side) with that error message on my desk. Process support helped me out >(by analyzing a TCP dump of the connection) which showed that one of the >firewalls responded to a keepalive packet with a RESET. > >So, you could as well try and start TCPware with /NOKEEPALIVE... Sorry, folks. No change with /NOKEEPALIVE. Seems I sometimes really have to dig into if I really want to know/fix it... But if you think about it, why should a change in TCPware affect only the TCPware FTP clients but not the MGFTP client (which continues to work) ? -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 14 Feb 2001 10:58:22 -0400 Date: Wed, 14 Feb 2001 10:56:48 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: [TCPware V5.4-3] still problems with FTP clients To: info-tcpware@process.com Message-ID: <3A8AAAC0.E7B6E903@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > >Richard Whalen (whalenr@process.com) wrote: > >> Peter "EPLAN" LANGSTOEGER wrote: > >> > all failed at about the time when the transfer is finished. That means I > >> > download for a couple of minutes (and a lot of lines of #) and then I get > >> > > >> > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection > >> > -SYSTEM-F-VCBROKEN, virtual circuit broken > >> > >> Since this problem happens with larger files (which presumably would take > >> longer), I would guess that the firewall is dropping what it believes to be > >> an inactive connection (the control connection). Make sure that TCPWARE is > >> NOT being started /NOKEEPALIVE (chapter 7-2 in the management guide), as > >> keepalives will help in persuading the firewall to keep the connection open. > >> Also look at the parameters of the firewall for when it drops inactive > >> connections. > > > >I just had a support case (5.3-3, two firewalls, UCX server on the other > >side) with that error message on my desk. Process support helped me out > >(by analyzing a TCP dump of the connection) which showed that one of the > >firewalls responded to a keepalive packet with a RESET. > > > >So, you could as well try and start TCPware with /NOKEEPALIVE... > > Sorry, folks. No change with /NOKEEPALIVE. > Seems I sometimes really have to dig into if I really want to know/fix it... > > But if you think about it, why should a change in TCPware affect only > the TCPware FTP clients but not the MGFTP client (which continues to work) ? > Not sure why you see a difference between MGFTP and the TCPware one. I'd be interested in seeing a TCPDUMP of this failing after you set the /NOKEEPALIVE. 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, 15 Feb 2001 13:22:35 -0400 Date: Thu, 15 Feb 2001 12:20:47 -0600 From: Jonathan Davis Reply-To: Info-TCPware@process.com Subject: Providing TFTP server information with DHCP server. To: info-tcpware@process.com Message-ID: <3A8C1DFF.6BEE8410@wku.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is it possible to provide TFTP server information using the DHCP server. In the manual there is an option listed as option tftp-server-name string; but I need to provide more information. Management here wants to try out voice over ip and for this they need the dhcp server to provide the tftp server name, definity clan ip, tftp directory, and tftp port. Apparently the hardware they want to use was designed with Windows in mind with seems to support all of this information. Thanks for any help. -- Jonathan Davis (Jonathan.Davis@wku.edu) System Administrator (745-5251) Network Computing Western Kentucky University ================================================================================ Archive-Date: Fri, 16 Feb 2001 10:31:01 -0400 Date: Fri, 16 Feb 2001 10:29:21 -0500 From: Ralph Young Reply-To: Info-TCPware@process.com Subject: RE: Providing TFTP server information with DHCP server. To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE86031CF06D@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 TCPware has a generic option for any DCHP option not listed in the DHCP options table : option option-nnn data-string; where nnn is the number of the option You'd first have to determine what your DHCP client is looking for in terms of the format for the tftp options you noted - clan ip, tftp directory, and tftp port. You may have a Windows DHCP server already providing these options? You could then get a trace of the data from the server and see how the data is represented so you could set up your data-string. -Ralph Young Process Software > -----Original Message----- > From: Jonathan Davis [mailto:Jonathan.Davis@wku.edu] > Sent: Thursday, February 15, 2001 1:21 PM > To: info-tcpware@process.com > Subject: Providing TFTP server information with DHCP server. > > > Is it possible to provide TFTP server information using the > DHCP server. In > the manual there is an option listed as option > tftp-server-name string; but I > need to provide more information. Management here wants to > try out voice over > ip and for this they need the dhcp server to provide the tftp > server name, > definity clan ip, tftp directory, and tftp port. Apparently > the hardware they > want to use was designed with Windows in mind with seems to > support all of > this information. > > Thanks for any help. > > -- > Jonathan Davis (Jonathan.Davis@wku.edu) > System Administrator (745-5251) > Network Computing > Western Kentucky University > ================================================================================ Archive-Date: Sun, 18 Feb 2001 13:02:29 -0400 Date: Fri, 16 Feb 2001 16:15:04 -0500 (EST) From: Geof Bryant Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V543P051 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01K06N09J2B60005NY@DELTA.PROCESS.COM> TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V543P051 Description: Privs not required to set TCP_NODELAY; VMS 7.2-1H1 hang Release date: 16-FEB-2001 Ranking: 3 Max ranking: 2 Versions: 5.4-3,5.3-3 ftp://ftp.process.com/support/54_3/drivers_v543p051.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- DRIVERS patch kit revision 5.1 for TCPware Version 5.4-3 02-Feb-2001 Copyright © 1999-2000 Process Software Corporation Copyright © 2000,2001 Process Software, LLC Highest ECO Rank 2 (Version 3.0) Version 5.1 Rank 3 This patch kit provides new versions of the following drivers for TCPware Version 5.4-3: DRIVERS_V543P051 - ECO rank: 3 ------------------ BGDRIVER - privs are no longer required for setting the TCP_NODELAY socket option. (D/E 6790) TCPDRIVER - On VMS version 7.2-1H1 a VMS problem can cause the NETCP process to go RWAST due to an outstanding direct I/O operation to a TCP device (IO$_CREATE). Changed IO$_CREATE to be a buffered I/O operation as workaraound. (D/E 6680) This kit also includes the following changes from previous ECO kits: For TCPware V5.4-3: DRIVERS_V543P042 - ECO rank: 3 ------------------ UCX$IPC_SHR - Support for aborting a select() call was required for compatibility with Oracle Version 8.1.6. (D/E 6619) DRIVERS_V543P030 - ECO rank: 2 ------------------ IPDRIVER - On some Alphas, VMS's VCI layer does not report a device error when a cable is unplugged from the network card. This version of IPDRIVER provides a workaround, which allows the paired network interface failover support to work. (D/E 6150) DRIVERS_V543P020 ------------------ BGDRIVER - Add support for "privileged sockets" to allow beta 2 of the Apache server from Compaq to work. (D/E 5732) - Add support for the DEC C values of the multicast options to BGDRIVER (actual change was to IPDRIVER). (D/E 5733) - Under certain circumstances, code introduced in DRIVERS_V543P020 could cause an Unexpected System Service Exception and crash the system when doing NETCU SET BG_TCP commands. (D/E 6224, D/E 6243) TCPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) UDPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) IPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) DRIVERS_V543P010 ------------------ TCPDRIVER - Changes made to the Outgoing Access Restrictions feature that corrects problems introduced in TCPware 5.4 and DRIVERS_V533P050. (D/E 5350) For TCPware V5.3-3: DRIVERS_V533P050 ------------------ BGDRIVER - Modify behaviour of IO$_DEACCESS (D/E 2298) - Modified to allow DCL/Perl scripts to work properly under the Netscape FastTrack web server. (D/E 3509) - Provide proper privilege checks under OpenVMS Alpha V7.2 and higher. (D/E 5296) INETDRIVER - Correct the output of an extra for output from REXEC (D/E 339) - Provide proper privilege checks under OpenVMS Alpha V7.2 and higher. (D/E 5296) IPDRIVER - Fix routine which derives largest MTU of all physical interfaces. This is used by TCP to set the MSS advertised at connection establishment. (D/E 2213) - EWA twisted pair Ethernet controllers with the cable removed would hang TCPware during startup. This problem has been corrected. (D/E 2453) - Provide proper privilege checks under OpenVMS Alpha V7.2 and higher. (D/E 5296) NTDRIVER - Drop any received data when closing. (D/E 3330) - Permanent NTA /w CLOSE_DASSGN cannot be deleted. (D/E 1537) - Provide proper privilege checks under OpenVMS Alpha V7.2 and higher. (D/E 5296) TCPDRIVER - Recognize SYN packets in successive connections when old connection is in TIME_WAIT (RLOGIN clients no longer hang on successive connections) (D/E 3872) - Provide proper privilege checks under OpenVMS Alpha V7.2 and higher. (D/E 5296) UDPDRIVER - Provide proper privilege checks under OpenVMS Alpha V7.2 and higher. (D/E 5296) NOTE: You must reboot your system after installing this patch in order to load the new driver(s). The old versions of the driver(s) will be renamed to *.EXE_OLD. Once installed, you may undo this patch by renaming the file(s) back to: TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE [End of ECO announcement] ================================================================================ Archive-Date: Tue, 20 Feb 2001 06:14:45 -0400 Date: Tue, 20 Feb 2001 11:11:04 +0000 From: Kevin Phillip Reply-To: Info-TCPware@process.com Subject: TCPware 5.4-3 - SNMP Issue To: "'info-tcpware@process.com'" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Hi there, We have a Compaq AlphaServer running OpenVMS V7.1-1H2 and the above software. We have installed Unicenter TNG agents (a Computer Associates software) on the server and are trying to get the agents to talk to our TNG server (using SNMP). But it doesn't seem to be working. I know it's a long shot, but I was wondering whether anyone has experienced this problem or whether there is an issue with TCPware working with TNG. Thanks, Kevin Phillip ************************************************************ CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments to it are for the exclusive use of the intended recipient(s). It may be confidential and contain privileged information and will be protected by copyright. If you are not the intended recipient(s) you must not review, copy, distribute or in any other way use or rely on the information contained in the message. If you have received this e-mail in error, please notify us by e-mail to Administrator@itex.je, Telephone: +44 1534 633633 or Fax: +44 1534 633644 and then delete all copies from your system. http://www.itex.je ================================================================================ Archive-Date: Tue, 20 Feb 2001 08:57:23 -0400 Date: Tue, 20 Feb 2001 08:54:52 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: RE: TCPware 5.4-3 - SNMP Issue To: info-tcpware@process.com Message-ID: <3A92772C.B2A737DA@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi there, > > We have a Compaq AlphaServer running OpenVMS V7.1-1H2 and the above > software. We have installed Unicenter TNG agents (a Computer Associates > software) on the server and are trying to get the agents to talk to our TNG > server (using SNMP). But it doesn't seem to be working. > > I know it's a long shot, but I was wondering whether anyone has experienced > this problem or whether there is an issue with TCPware working with TNG. > > Thanks, > > > Kevin Phillip Kevin, Could you tell us what error or messages that you are getting? Have you enabled the SNMP on the TCPware system. If you do a NETCU SHOW CONN/ALL do you see a line - ID RecvQ SendQ Local Address Foreign Address State -- ----- ----- ------------- --------------- ----- BGxx 0 0 *.snmp *.* 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: Wed, 21 Feb 2001 05:34:26 -0400 Date: Wed, 21 Feb 2001 10:30:48 +0000 From: Kevin Phillip Reply-To: Info-TCPware@process.com Subject: RE: TCPware 5.4-3 - SNMP Issue To: "'Info-TCPware@process.com'" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Hi Michael, We managed to install some patches over the weekend and have found that it's now working! Thanks for your help anyway. Regards, Kevin..... -----Original Message----- From: Michael Corbett [mailto:corbett@process.com] Sent: 20 February 2001 13:55 To: info-tcpware@process.com Subject: RE: TCPware 5.4-3 - SNMP Issue > Hi there, > > We have a Compaq AlphaServer running OpenVMS V7.1-1H2 and the above > software. We have installed Unicenter TNG agents (a Computer Associates > software) on the server and are trying to get the agents to talk to our TNG > server (using SNMP). But it doesn't seem to be working. > > I know it's a long shot, but I was wondering whether anyone has experienced > this problem or whether there is an issue with TCPware working with TNG. > > Thanks, > > > Kevin Phillip Kevin, Could you tell us what error or messages that you are getting? Have you enabled the SNMP on the TCPware system. If you do a NETCU SHOW CONN/ALL do you see a line - ID RecvQ SendQ Local Address Foreign Address State -- ----- ----- ------------- --------------- ----- BGxx 0 0 *.snmp *.* 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 ************************************************************ CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments to it are for the exclusive use of the intended recipient(s). It may be confidential and contain privileged information and will be protected by copyright. If you are not the intended recipient(s) you must not review, copy, distribute or in any other way use or rely on the information contained in the message. If you have received this e-mail in error, please notify us by e-mail to Administrator@itex.je, Telephone: +44 1534 633633 or Fax: +44 1534 633644 and then delete all copies from your system. http://www.itex.je ================================================================================ Archive-Date: Thu, 22 Feb 2001 11:31:57 -0400 Date: Thu, 22 Feb 2001 09:30:02 -0700 From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: RE: TCPware 5.4-3 - SNMP Issue In-Reply-To: To: info-tcpware@process.com Message-ID: <5.0.2.1.2.20010222092905.03034b30@mehlhop.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Can you tell us what patches you installed for future reference? Jim At 10:30 AM 2/21/01 +0000, you wrote: >Hi Michael, > >We managed to install some patches over the weekend and have found that it's >now working! > >Thanks for your help anyway. > >Regards, > >Kevin..... > >-----Original Message----- >From: Michael Corbett [mailto:corbett@process.com] >Sent: 20 February 2001 13:55 >To: info-tcpware@process.com >Subject: RE: TCPware 5.4-3 - SNMP Issue > > > > > Hi there, > > > > We have a Compaq AlphaServer running OpenVMS V7.1-1H2 and the above > > software. We have installed Unicenter TNG agents (a Computer Associates > > software) on the server and are trying to get the agents to talk to our >TNG > > server (using SNMP). But it doesn't seem to be working. > > > > I know it's a long shot, but I was wondering whether anyone has >experienced > > this problem or whether there is an issue with TCPware working with TNG. > > > > Thanks, > > > > > > Kevin Phillip > >Kevin, > > Could you tell us what error or messages that you are getting? >Have you enabled the SNMP on the TCPware system. If you do a >NETCU SHOW CONN/ALL do you see a line - > >ID RecvQ SendQ Local Address Foreign Address State >-- ----- ----- ------------- --------------- ----- >BGxx 0 0 *.snmp *.* > >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 > > >************************************************************ >CONFIDENTIALITY NOTICE >The information contained in this e-mail and any attachments >to it are for the exclusive use of the intended recipient(s). >It may be confidential and contain privileged information >and will be protected by copyright. >If you are not the intended recipient(s) you must not review, >copy, distribute or in any other way use or rely on the >information contained in the message. >If you have received this e-mail in error, please notify us >by e-mail to Administrator@itex.je, Telephone: +44 1534 633633 >or Fax: +44 1534 633644 and then delete all copies from your >system. > >http://www.itex.je _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Thu, 22 Feb 2001 11:47:58 -0400 Date: Thu, 22 Feb 2001 16:44:11 +0000 From: Kevin Phillip Reply-To: Info-TCPware@process.com Subject: RE: TCPware 5.4-3 - SNMP Issue To: "'Info-TCPware@process.com'" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Well, basically we downloaded and installed all patches for that particular version of TCPware. So it could be one or a combination of a few! I do apologise for not being specific. Regards, Kevin.... -----Original Message----- From: Jim Mehlhop [mailto:mehlhop@process.com] Sent: 22 February 2001 16:30 To: info-tcpware@process.com Subject: RE: TCPware 5.4-3 - SNMP Issue Can you tell us what patches you installed for future reference? Jim At 10:30 AM 2/21/01 +0000, you wrote: >Hi Michael, > >We managed to install some patches over the weekend and have found that it's >now working! > >Thanks for your help anyway. > >Regards, > >Kevin..... > >-----Original Message----- >From: Michael Corbett [mailto:corbett@process.com] >Sent: 20 February 2001 13:55 >To: info-tcpware@process.com >Subject: RE: TCPware 5.4-3 - SNMP Issue > > > > > Hi there, > > > > We have a Compaq AlphaServer running OpenVMS V7.1-1H2 and the above > > software. We have installed Unicenter TNG agents (a Computer Associates > > software) on the server and are trying to get the agents to talk to our >TNG > > server (using SNMP). But it doesn't seem to be working. > > > > I know it's a long shot, but I was wondering whether anyone has >experienced > > this problem or whether there is an issue with TCPware working with TNG. > > > > Thanks, > > > > > > Kevin Phillip > >Kevin, > > Could you tell us what error or messages that you are getting? >Have you enabled the SNMP on the TCPware system. If you do a >NETCU SHOW CONN/ALL do you see a line - > >ID RecvQ SendQ Local Address Foreign Address State >-- ----- ----- ------------- --------------- ----- >BGxx 0 0 *.snmp *.* > >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 > > >************************************************************ >CONFIDENTIALITY NOTICE >The information contained in this e-mail and any attachments >to it are for the exclusive use of the intended recipient(s). >It may be confidential and contain privileged information >and will be protected by copyright. >If you are not the intended recipient(s) you must not review, >copy, distribute or in any other way use or rely on the >information contained in the message. >If you have received this e-mail in error, please notify us >by e-mail to Administrator@itex.je, Telephone: +44 1534 633633 >or Fax: +44 1534 633644 and then delete all copies from your >system. > >http://www.itex.je _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ************************************************************ CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments to it are for the exclusive use of the intended recipient(s). It may be confidential and contain privileged information and will be protected by copyright. If you are not the intended recipient(s) you must not review, copy, distribute or in any other way use or rely on the information contained in the message. If you have received this e-mail in error, please notify us by e-mail to Administrator@itex.je, Telephone: +44 1534 633633 or Fax: +44 1534 633644 and then delete all copies from your system. http://www.itex.je ================================================================================ Archive-Date: Thu, 22 Feb 2001 11:56:28 -0400 Date: Thu, 22 Feb 2001 09:54:32 -0700 From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: RE: TCPware 5.4-3 - SNMP Issue In-Reply-To: To: info-tcpware@process.com Message-ID: <5.0.2.1.2.20010222095414.03021cb0@mehlhop.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii OK thanks for the feedback Jim At 04:44 PM 2/22/01 +0000, Kevin Phillip wrote: >Well, basically we downloaded and installed all patches for that particular >version of TCPware. So it could be one or a combination of a few! > >I do apologise for not being specific. > >Regards, Kevin.... > >-----Original Message----- >From: Jim Mehlhop [mailto:mehlhop@process.com] >Sent: 22 February 2001 16:30 >To: info-tcpware@process.com >Subject: RE: TCPware 5.4-3 - SNMP Issue > > >Can you tell us what patches you installed for future reference? > >Jim >At 10:30 AM 2/21/01 +0000, you wrote: > >Hi Michael, > > > >We managed to install some patches over the weekend and have found that >it's > >now working! > > > >Thanks for your help anyway. > > > >Regards, > > > >Kevin..... > > > >-----Original Message----- > >From: Michael Corbett [mailto:corbett@process.com] > >Sent: 20 February 2001 13:55 > >To: info-tcpware@process.com > >Subject: RE: TCPware 5.4-3 - SNMP Issue > > > > > > > > > Hi there, > > > > > > We have a Compaq AlphaServer running OpenVMS V7.1-1H2 and the above > > > software. We have installed Unicenter TNG agents (a Computer Associates > > > software) on the server and are trying to get the agents to talk to our > >TNG > > > server (using SNMP). But it doesn't seem to be working. > > > > > > I know it's a long shot, but I was wondering whether anyone has > >experienced > > > this problem or whether there is an issue with TCPware working with TNG. > > > > > > Thanks, > > > > > > > > > Kevin Phillip > > > >Kevin, > > > > Could you tell us what error or messages that you are getting? > >Have you enabled the SNMP on the TCPware system. If you do a > >NETCU SHOW CONN/ALL do you see a line - > > > >ID RecvQ SendQ Local Address Foreign Address State > >-- ----- ----- ------------- --------------- ----- > >BGxx 0 0 *.snmp *.* > > > >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 > > > > > >************************************************************ > >CONFIDENTIALITY NOTICE > >The information contained in this e-mail and any attachments > >to it are for the exclusive use of the intended recipient(s). > >It may be confidential and contain privileged information > >and will be protected by copyright. > >If you are not the intended recipient(s) you must not review, > >copy, distribute or in any other way use or rely on the > >information contained in the message. > >If you have received this e-mail in error, please notify us > >by e-mail to Administrator@itex.je, Telephone: +44 1534 633633 > >or Fax: +44 1534 633644 and then delete all copies from your > >system. > > > >http://www.itex.je > > >_________________________________________________________________________ > Jim Mehlhop, Support Engineer > Process Software > Mehlhop@process.com > Phone 719-638-8448 > Join Cauce to outlaw spam > http://www.cauce.org/ > >_________________________________________________________________________ > > >************************************************************ >CONFIDENTIALITY NOTICE >The information contained in this e-mail and any attachments >to it are for the exclusive use of the intended recipient(s). >It may be confidential and contain privileged information >and will be protected by copyright. >If you are not the intended recipient(s) you must not review, >copy, distribute or in any other way use or rely on the >information contained in the message. >If you have received this e-mail in error, please notify us >by e-mail to Administrator@itex.je, Telephone: +44 1534 633633 >or Fax: +44 1534 633644 and then delete all copies from your >system. > >http://www.itex.je _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Fri, 23 Feb 2001 06:43:02 -0400 Date: Fri, 23 Feb 2001 11:40:53 +0000 From: Andy Williams Reply-To: Info-TCPware@process.com Subject: FTP transfer timings To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 TCPware V5.3-2 and V5.4-3 (both VAX and Alpha) We spend lots of time FTPing files from UNIX systems to VMS and back and I got asked today how we can enable the kind of 'statistics' reporting that thing like UNIX or TCP/IP Services reports, such as "xxx bytes sent in hh:mm:ss seconds (yyy Kbytes/s)". I've looked through the FTP documentation & nothing obvious stands out. Is there an easy way to enable this in TCPware ? ---------------------------------------------------------------------- The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies. ---------------------------------------------------------------------- ================================================================================ Archive-Date: Fri, 23 Feb 2001 09:54:05 -0400 Date: Fri, 23 Feb 2001 15:53:12 +0100 From: "Truemper, Harald" Reply-To: Info-TCPware@process.com Subject: TFTP problems To: info-tcpware@process.com Message-ID: Hi all, actually I have a big problem running TFTP services (UDP port 69) on my Alpha (OpenVMS AXP 7.1 / TCPWARE 5.3-2). Since yesterday something killed this service without any alarm messages. NETCP.LOG / OPERATOR.LOG shows no entries about this issue. Then I must restart the service with the command @CNFNET MISC. And then only 5-10 transfer runs well and then the service is down again. I tried it out with 5 clients. All of them show the same "out of time messages" after some transfers. I tried to setup the service with \OUTPUT=TCPWARE:TFTP_ERR.LOG. But in this file only the start of the process is mentioned. Do you have an idea who I have to detemine this killings ? All other services are running well. Thanks for any help > Honeywell Specialty Chemicals Seelze GmbH > Harald Truemper > AL-LIM > Wunstorfer Stra?e 40 > D-30926 Seelze > > *+49 5137 999-417 > *+49 5137 999-164 > *+49 171 8106752 > > > > ================================================================================ Archive-Date: Fri, 23 Feb 2001 10:06:08 -0400 Date: Fri, 23 Feb 2001 10:03:37 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: RE: FTP transfer timings To: info-tcpware@process.com Message-ID: <3A967BC9.B9359E77@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > TCPware V5.3-2 and V5.4-3 (both VAX and Alpha) > > We spend lots of time FTPing files from UNIX systems to VMS and back and I > got asked today how we can enable the kind of 'statistics' reporting that > thing like UNIX or TCP/IP Services reports, such as "xxx bytes sent in > hh:mm:ss seconds (yyy Kbytes/s)". I've looked through the FTP documentation > & nothing obvious stands out. > > Is there an easy way to enable this in TCPware ? > What you are looking for is in TCPware 5.4 which is currently in BETA test. TCPware 5.4 will include FTP accounting and FTP statistics which will be made available through SNMP. regards Michael -- +-------------------------------------------------------------------------+ 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, 23 Feb 2001 10:22:36 -0400 Date: Fri, 23 Feb 2001 16:17:08 +0100 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: TFTP problems To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a967ef4$1@news.kapsch.co.at> In article , "Truemper, Harald" writes: >actually I have a big problem running TFTP services (UDP port 69) on my >Alpha (OpenVMS AXP 7.1 / TCPWARE 5.3-2). > >Do you have an idea who I have to detemine this killings ? Add /ACC instead of /NOACC to the service definition and you have an entry in the accounting file.., But: There is a service process for every transfer which doesn't get reused and therefor dies at the end of the transfer (without timeout limit). So, the process accounting won't help you, if NETCP really does suddenly stop creating new TFTP daemons while connection requests still come in... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Fri, 23 Feb 2001 10:22:48 -0400 Date: Fri, 23 Feb 2001 16:18:23 +0100 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: RE: FTP transfer timings To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a967f3f$1@news.kapsch.co.at> In article <3A967BC9.B9359E77@PROCESS.COM>, Michael Corbett writes: >What you are looking for is in TCPware 5.4 which is currently in BETA >test. TCPware 5.4 will include FTP accounting and FTP statistics which >will be made available through SNMP. Make this TCPware V5.5 and please someone let me access it ASAP ;-) -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Fri, 23 Feb 2001 10:53:49 -0400 Date: Fri, 23 Feb 2001 10:51:17 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: RE: FTP transfer timings To: info-tcpware@process.com Message-ID: <3A9686F5.24589E84@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > In article <3A967BC9.B9359E77@PROCESS.COM>, Michael Corbett writes: > >What you are looking for is in TCPware 5.4 which is currently in BETA > >test. TCPware 5.4 will include FTP accounting and FTP statistics which > >will be made available through SNMP. > > Make this TCPware V5.5 > and please someone let me access it ASAP ;-) > Yes, it should be V5.5. If you are serious about wanting to try the BETA test kit send me a message. 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: Fri, 23 Feb 2001 11:01:55 -0400 Date: Fri, 23 Feb 2001 15:59:49 +0000 From: Andy Williams Reply-To: Info-TCPware@process.com Subject: RE: FTP transfer timings To: "'Info-TCPware@process.com'" CC: "'corbett@process.com'" Message-ID: MIME-Version: 1.0 Content-Type: text/plain Thanks for the update. Unfortunately these are production systems & I'd be hung, drawn, quartered & told to spend a month on UNIX for suggesting we load beta software up. It's not the hanging, drawing or quartering that worries me.... -Andy -----Original Message----- From: Michael Corbett [mailto:corbett@process.com] Sent: Friday, February 23, 2001 3:51 PM To: info-tcpware@process.com Subject: RE: FTP transfer timings *********************************************************************** IMPORTANT - This email originates from the Internet & therefore may not be from the apparent sender. If you have any doubts about the origin or content of the email please contact PC Support on ext. 2288. *********************************************************************** > In article <3A967BC9.B9359E77@PROCESS.COM>, Michael Corbett writes: > >What you are looking for is in TCPware 5.4 which is currently in BETA > >test. TCPware 5.4 will include FTP accounting and FTP statistics which > >will be made available through SNMP. > > Make this TCPware V5.5 > and please someone let me access it ASAP ;-) > Yes, it should be V5.5. If you are serious about wanting to try the BETA test kit send me a message. 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 ---------------------------------------------------------------------- The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies. ---------------------------------------------------------------------- ================================================================================ Archive-Date: Fri, 23 Feb 2001 12:25:40 -0400 Date: Fri, 23 Feb 2001 18:09:16 +0100 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: HOSTS file To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a96993c$1@news.kapsch.co.at> How is the hosts file handled ? Seeked through before or after BIND/DNS ? Is this configurable ? Is the hosts file dynamic ? Will TCPware automatically detect hosts file content changes ? Or is there a command (like RELOAD) ? What is the hosts file for at all, if someone uses DNS ? U**X systems have at least their own name in, but TCPware has this one already in the TCPWARE_CONFIGURE.COM. Should I keep the hosts file empty ? Any comments ? TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Fri, 23 Feb 2001 13:04:26 -0400 Date: Fri, 23 Feb 2001 18:08:48 +0000 From: Tremaine Callier Reply-To: Info-TCPware@process.com Subject: RE: HOSTS file To: "'Info-TCPware@process.com'" Message-ID: <1156FD036CD3D411B2EC009027991461637A35@THE-EXCHCLST.integralis.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 the TCPWARE_SVCORDER logical handles the search order. The hosts file is reread at least every 10 mins. I would guess @tcpware:restart dns would force the reload Tremaine -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: 23 February 2001 17:09 To: info-tcpware@process.com Subject: HOSTS file How is the hosts file handled ? Seeked through before or after BIND/DNS ? Is this configurable ? Is the hosts file dynamic ? Will TCPware automatically detect hosts file content changes ? Or is there a command (like RELOAD) ? What is the hosts file for at all, if someone uses DNS ? U**X systems have at least their own name in, but TCPware has this one already in the TCPWARE_CONFIGURE.COM. Should I keep the hosts file empty ? Any comments ? TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" Integralis Theale House Brunel Road Theale, Reading RG7 4AQ +44 (0) 118 9306060 A member of the Articon-Integralis Group info@Integralis.com http://www.integralis.com DISCLAIMER Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error please notify the IT manager by telephone on +44 (0)118 930 6060 or via email to internal.security@integralis.com, including a copy of this message. Please then delete this email and destroy any copies of it. ================================================================================ Archive-Date: Fri, 23 Feb 2001 13:27:49 -0400 Date: Fri, 23 Feb 2001 13:25:53 -0500 (EST) From: Jeff Schreiber Reply-To: Info-TCPware@process.com Subject: Re: FTP transfer timings To: info-tcpware@process.com Message-ID: <01K0G91WZQWY9PQ4DW@ALCOR.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Michael Corbett writes: > > >> >> TCPware V5.3-2 and V5.4-3 (both VAX and Alpha) >> >> We spend lots of time FTPing files from UNIX systems to VMS and back and I >> got asked today how we can enable the kind of 'statistics' reporting that >> thing like UNIX or TCP/IP Services reports, such as "xxx bytes sent in >> hh:mm:ss seconds (yyy Kbytes/s)". I've looked through the FTP documentation >> & nothing obvious stands out. >> >> Is there an easy way to enable this in TCPware ? >> > >What you are looking for is in TCPware 5.4 which is currently in BETA >test. TCPware 5.4 will include FTP accounting and FTP statistics which >will be made available through SNMP. > (as mentioned, 5.5). It sounds like your looking for the client statistics, not the server statistics that Mike is referring to. If you add /log to your gets and puts, I think that'll give you what you are looking for: FTP> get/log mail.dmp 200 STRU command okay. 200 TYPE command okay. 200 PORT command okay. 150 Opening data connection for DISK$SYS_LOGIN:[LOGIN.SCHREIBER]MAIL.DMP;6 (9146 368 bytes). 226 Closing data connection. 9145392 (8) bytes transferred. %TCPWARE_FTP-I-COPIED, ALCOR.process.com"schreiber password"::mail.dmp copied to DISK$SYS_LOGIN:[LOGIN.SCHREIBER]MAIL.DMP;7 -TCPWARE-I-RATE, 9145392 bytes transferred in 6.86 seconds (1300.006 KB/sec) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Jeff -- Jeff Schreiber, Process Software LLC schreiber@mx.process.com http://www.process.com TCPware, MultiNet & PMDF: Stronger than Ever ================================================================================ Archive-Date: Fri, 23 Feb 2001 13:47:41 -0400 Date: Fri, 23 Feb 2001 12:44:32 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com Subject: Re: HOSTS file Sender: DLUTES@fw2.dc1.textron.com To: info-tcpware@process.com Message-ID: <3A965B2F.5C156216@cessna.textron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3a96993c$1@news.kapsch.co.at> Peter LANGSTOEGER wrote: > What is the hosts file for at all, if someone uses DNS ? Tremain answered most of Peter's questions, but let me tell you why we use both. In my company, the main I.S. department maintains the DNS servers on some brand X machines. We have had a lot of trouble with this arrangement in the past. The server(s) have gone down, the network between my lab and the servers has gone down, and servers' own addresses have been changed without notification. My lab occasionally monitors test aircraft in flight. The monitoring systems communicate with each other via the network. We can't afford to have these systems affected by DNS and other network goof-ups outside of our area. Therefore all of our systems look at their local host file first, giving us complete control of address resolution for our most important systems. Non-critical components (such as printers) are left up to the company DNS server. -- Dale D. Lutes Flight Data Systems Cessna Aircraft Company 316-517-7109 ================================================================================ Archive-Date: Fri, 23 Feb 2001 14:13:43 -0400 Date: Fri, 23 Feb 2001 14:11:47 -0500 (EST) From: Jeff Schreiber Reply-To: Info-TCPware@process.com Subject: Re: HOSTS file To: info-tcpware@process.com Message-ID: <01K0GACTTX0Y9PQ5A4@ALCOR.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii eplan@kapsch.net (Peter LANGSTOEGER) writes: > >How is the hosts file handled ? It is checked before or after a query to DNS. >Seeked through before or after BIND/DNS ? Yes. :) >Is this configurable ? Yes. The order is defined by the tcpware_svcorder logical. If you set it from the default of "bind,local" to "local,bind" it will check the hosts table first before querying DNS. >Is the hosts file dynamic ? Yes. >Will TCPware automatically detect hosts file content changes ? Yes. As mentioned, every 10 minutes. this check can be changed with the tcpware_res_reload_check_intvl logical, which can be defined to a delta time. >Or is there a command (like RELOAD) ? There isn't one yet [the infrastructure is there, but the support isn't in the drivers yet]. It's an idea that I've been considering but I'm not sure if it's really nessessary. You can similarly 'force' a reload by defining the reload_check_intvl logical to something really low [like a second], and then query something that won't exist. It'll cause the file to reload, and then remove that logical [or put it back to what it was before], and it'll go back to the other time. >What is the hosts file for at all, if someone uses DNS ? >U**X systems have at least their own name in, >but TCPware has this one already in the TCPWARE_CONFIGURE.COM. The name in the tcpware_configure.com doesn't effect hostname lookup at all. Some people use the hosts database for a number of different things. I occasionally have short names for systems that I go to often, and I know the IP addresses won't change [like "t" to be my test system]. Some people use it as a fallback [like me] in case there is DNS problems [which is quite common on my systems when I do DNS development, it's not always there! :)]. E.g. if your gateway is a fixed IP address, and you want to be able to reference it by name even when your having network issues, you might put the mapping in the hosts table so you can always get to it easily. Some people switch the order and have the local hosts checked first, so that frequent fixed IP address systems can be resolved quicker, without the UDP delays that come into play with DNS. This of course is a little dangerous, as if the IP address changes, you have to specifically change it in all your hosts files. >Should I keep the hosts file empty ? All depends on your needs. If you don't want to use it, you can leave it blank. -Jeff -- Jeff Schreiber, Process Software LLC schreiber@mx.process.com http://www.process.com TCPware, MultiNet & PMDF: Stronger than Ever ================================================================================ Archive-Date: Tue, 27 Feb 2001 09:44:18 -0500 Date: Tue, 27 Feb 2001 09:45:34 -0500 From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com Subject: telnet/perm To: info-tcpware@process.com Message-ID: <010227094534.1bdda@ENDOR.COM> VMS 7.2-1 TCPWARE 5.4, 5.5 I create a permanent device with telnet using $ telnet/create=(perm)/logical=test_direct_1/table=system 192.192.8.200 6999 Which gives me a NTA device. This device works fine. However after a timeout, and I notice that the device is set to unavailable. I talk to the port using sys$qio. I can change the state of the port by doing the following $ SET HOST/DTE NTA4: !or whatever the port name is. I notice that by just issuing the command the port becomes available and an TCPDUMP indicates characters sent. How or what do I need to do in sys$qio to "wake" the port up to change the state from unavailable to available just like the SET HOST/DTE command does. What does SET HOST/DTE do when the command is issued john babiarz ================================================================================ Archive-Date: Tue, 27 Feb 2001 09:47:17 -0500 Date: Tue, 27 Feb 2001 09:48:44 -0500 From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com Subject: Autoreponder needed To: info-tcpware@process.com Message-ID: <010227094844.1bdda@ENDOR.COM> VMS 7.2-1, TCPWARE 5.4, TCPWARE 5.5 Is there an autoreponder for tcpware using the default SMTP mail server? john babiarz ================================================================================ Archive-Date: Tue, 27 Feb 2001 10:28:35 -0500 Date: Tue, 27 Feb 2001 10:25:23 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: RE: telnet/perm - device unavailable. To: info-tcpware@process.com Message-ID: <3A9BC6E3.8FD16862@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > VMS 7.2-1 TCPWARE 5.4, 5.5 > > I create a permanent device with telnet using > > $ telnet/create=(perm)/logical=test_direct_1/table=system 192.192.8.200 6999 > > > Which gives me a NTA device. > > This device works fine. However after a timeout, and I notice that the device > is set to unavailable. I talk to the port using sys$qio. I can change the > state of the port by doing the following > > > $ SET HOST/DTE NTA4: !or whatever the port name is. > > I notice that by just issuing the command the port becomes available and > an TCPDUMP indicates characters sent. > > How or what do I need to do in sys$qio to "wake" the port up to change the > state from unavailable to available just like the SET HOST/DTE command does. > What does SET HOST/DTE do when the command is issued > > > john babiarz > John, From my playing with this it appears that the device becomes avaiable as soon as something has a channel assigned to it and the connection is established. I'm not sure why this is. Do you have something that requires that the device no be in an unavailable state? 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: Tue, 27 Feb 2001 10:42:19 -0500 Date: Tue, 27 Feb 2001 09:32:03 -0600 (CST) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: Autoreponder needed In-Reply-To: "Your message dated Tue, 27 Feb 2001 09:48:44 -0500" <010227094844.1bdda@ENDOR.COM> To: info-tcpware@process.com Message-ID: <01K0LMFGSDH68WVYKF@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Info-TCPware@process.com wrote: > >VMS 7.2-1, TCPWARE 5.4, TCPWARE 5.5 > >Is there an autoreponder for tcpware using the default SMTP >mail server? > No. You can implement such a thing using the freeware DELIVER package, or by using the TCP SMTP server to route messages through a .COM file that generates the responses. But I don't know of anyone who's ever written one. I've always thought they were evil, so I've never done one. There's also WATCH_MAIL, from the freeware CD, I think, but it'll happily repy to lists, so you should use it (or any of these things) with caution. Be sure they reply to the MAIL FROM: envelope address and not the RFC822 From: or Reply-To: headers. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Tue, 27 Feb 2001 10:50:28 -0500 Date: Tue, 27 Feb 2001 10:51:41 -0500 From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com Subject: RE: telnet/perm - device unavailable. To: info-tcpware@process.com Message-ID: <010227105141.1bdda@ENDOR.COM> >> >> VMS 7.2-1 TCPWARE 5.4, 5.5 >> >> I create a permanent device with telnet using >> >> $ telnet/create=(perm)/logical=test_direct_1/table=system 192.192.8.200 6999 >> >> >> Which gives me a NTA device. >> >> This device works fine. However after a timeout, and I notice that the device >> is set to unavailable. I talk to the port using sys$qio. I can change the >> state of the port by doing the following >> >> >> $ SET HOST/DTE NTA4: !or whatever the port name is. >> >> I notice that by just issuing the command the port becomes available and >> an TCPDUMP indicates characters sent. >> >> How or what do I need to do in sys$qio to "wake" the port up to change the >> state from unavailable to available just like the SET HOST/DTE command does. >> What does SET HOST/DTE do when the command is issued >> >> >> john babiarz >> > > >John, > > From my playing with this it appears that the device becomes avaiable >as soon as something has a channel assigned to it and the connection is >established. I'm not sure why this is. Do you have something that requires >that the device no be in an unavailable state? > >regards >Mike > Mike, the remote device is beyond my control. The remote device will "reset/drop" the port after 1 min of inactivity. The device/port is set up externally, ie DCL/TENET command. The program when is starts up trys to allocate the device. The device can not be allocated if it is unavailable. How can I assign a channel to a device and not allocate it? As long as the device is in "available mode" I can handle it just like a regular LAT port. Once it goes into "unavailable mode" I must do a SET HOST/DTE to wake it up. After which, it is once again in "available mode" and the program allocates the device just fine. It would be interesting to note what set host/dte does. Just the very action of set host/dte "wakes up" the port. By the way, I can get you a TCPDUMP of the set host, but it must be kept private. john ================================================================================ Archive-Date: Tue, 27 Feb 2001 11:53:20 -0500 Date: Tue, 27 Feb 2001 17:38:04 +0100 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: telnet/perm To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a9bd7ec$1@news.kapsch.co.at> In article <010227094534.1bdda@ENDOR.COM>, babiarz@ENDOR.COM writes: >VMS 7.2-1 TCPWARE 5.4, 5.5 > >I create a permanent device with telnet using > >$ telnet/create=(perm)/logical=test_direct_1/table=system 192.192.8.200 6999 This reminds me of the TELNET/CREATE tests I did many many years ago. I found this feature useless then. Maybe it is changed now (that's also the reason why I write this) Years ago, it was: 1) With TELNET/CREATE you create a NTA device, but ONLY if the remote system is up. That means the IP connection is really and immediately established and keeps established. This behavious made the feature useless for eg. a VMS startup ([re]booting a system while eg. printers are switched off). and made it also very expensive if you have dial-up links in your network while having the keepalive feature in TCPware enabled. 2) Disconnecting the IP connection (eg. by turning off the printer, or rebooting a router, ...) made the TNA device 'unavailable' and there was _no_ way to get it 'online' again. So, you had to delete (the queue and) the NTA device and create it again after the IP connection went up again. This behaviour made it again useless. The suggested/expected behaviour of a TNA device was just like a LTA device. Creating the device doesn't establish an IP connection. IP connection would only be created, if a I/O channel gets assigned to the NTA device. With this behaviour, one can use the TNA device for everything and eg. with the LATSYM even as a device where you set a print queue up on. Then years went on and I did all printer queues with the IP feature of DCPS and so haven't watched the NTA behaviour of TCPware for a looong time. So, please, is the NTA behaviour still as useless as it was many years ago, or did it finally improve (and how) since then ? Many TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 27 Feb 2001 11:53:29 -0500 Date: Tue, 27 Feb 2001 17:42:09 +0100 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: telnet/perm To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3a9bd8e1$1@news.kapsch.co.at> In article <3a9bd7ec$1@news.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >The suggested/expected behaviour of a TNA device was just like a LTA device. >Creating the device doesn't establish an IP connection. IP connection would >only be created, if a I/O channel gets assigned to the NTA device. >With this behaviour, one can use the TNA device for everything and eg. >with the LATSYM even as a device where you set a print queue up on. I forgot: I never did understand, why this feature was done in the TELNET client and not in the NETCU: $ NETCU CREATE DEVICE $ NETCU SHOW DEVICE $ NETCU DELETE DEVICE just like with LATCP... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 27 Feb 2001 12:02:55 -0500 Sender: goatley@triton.process.com Return-Path: Date: Tue, 27 Feb 2001 12:02:14 -0500 From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com Subject: Re: telnet/perm To: info-tcpware@process.com Message-ID: <010227120214.1bdda@ENDOR.COM> I change the program from using sys$alloc to sys$assign and it worked properly. I am at a loss why sys$assign would do the deed, and sys$alloc would not. Strange but it now works! john