Archive-Date: Tue, 1 Jun 1999 06:40:24 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: RWAST Processes Date: Tue, 1 Jun 1999 11:39:00 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, I've got a couple of processes hanging around in RWAST state. These are all incoming telnet connections, and appear to be quite old (TCPware v5.3-3) I've logged a call with Compaq to get them to investigate the processes and get back to me, but thought I'd post it here as well. Interestingly, the show call from SDA> shows the same return address for all of the processes: SDA> show call Call Frame Information ---------------------- Stack Frame Procedure Descriptor Flags: Base Register = FP, No Jacket, Native Procedure Entry: FFFFFFFF.8008EF40 SYS$QIOW_C Return address on stack = FFFFFFFF.80086FD8 EXE$DASSGN_C+00198 Registers saved on stack ------------------------ 7FFA1EC0 00000000.00000020 Saved R2 7FFA1EC8 FFFFFFFF.85D3CAE0 Saved R3 EXE$CMODEXECX 7FFA1ED0 FFFFFFFF.81193580 Saved R4 PCB 7FFA1ED8 00000000.7FFA1F40 Saved R29 Regards, Derek... ================================================================================ Archive-Date: Tue, 1 Jun 1999 10:23:25 -0400 Message-ID: <4.1.19990601082447.00b75cc0@mehlhop.org> Date: Tue, 01 Jun 1999 08:26:20 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: RWAST Processes In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" This typically means that an IO device (the one being Deassigned) still has an IO outstanding. Have you heard back from DEC (Digital Enhanced Compaq) yet? Have you logged a call with us? Jim At 11:39 AM 6/1/99 +0100, you wrote: >Hi there, > >I've got a couple of processes hanging around in RWAST state. These are all >incoming telnet connections, and appear to be quite old (TCPware v5.3-3) > >I've logged a call with Compaq to get them to investigate the processes and >get back to me, but thought I'd post it here as well. > >Interestingly, the show call from SDA> shows the same return address for all >of the processes: > >SDA> show call > >Call Frame Information >---------------------- > Stack Frame Procedure Descriptor >Flags: Base Register = FP, No Jacket, Native > Procedure Entry: FFFFFFFF.8008EF40 SYS$QIOW_C > Return address on stack = FFFFFFFF.80086FD8 EXE$DASSGN_C+00198 > >Registers saved on stack >------------------------ >7FFA1EC0 00000000.00000020 Saved R2 >7FFA1EC8 FFFFFFFF.85D3CAE0 Saved R3 EXE$CMODEXECX >7FFA1ED0 FFFFFFFF.81193580 Saved R4 PCB >7FFA1ED8 00000000.7FFA1F40 Saved R29 > >Regards, > >Derek... _________________________________________________________________________ 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, 1 Jun 1999 11:03:45 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: RWAST Processes Date: Tue, 1 Jun 1999 16:02:25 +0100 MIME-Version: 1.0 Content-Type: text/plain Jim, Compaq have investigated and said that the processes appear to be waiting for I/O completion from one of our disks (although this appears to be fine). The first-level guy has escalated this and will get back to me. I was planning on waiting until I had more info from Compaq prior to logging this with my TCPware supplier. Just thought I'd post a quick message on the newsgroup in the meantime. I'll let you know what Compaq come back with (and log a call if required). Derek... > -----Original Message----- > From: Jim Mehlhop [SMTP:mehlhop@process.com] > Sent: 01 June 1999 15:26 > To: Info-TCPware@process.com > Subject: Re: RWAST Processes > > This typically means that an IO device (the one being Deassigned) still > has > an IO outstanding. Have you heard back from DEC (Digital Enhanced Compaq) > yet? > > Have you logged a call with us? > > Jim > > At 11:39 AM 6/1/99 +0100, you wrote: > >Hi there, > > > >I've got a couple of processes hanging around in RWAST state. These are > all > >incoming telnet connections, and appear to be quite old (TCPware v5.3-3) > > > >I've logged a call with Compaq to get them to investigate the processes > and > >get back to me, but thought I'd post it here as well. > > > >Interestingly, the show call from SDA> shows the same return address for > all > >of the processes: > > > >SDA> show call > > > >Call Frame Information > >---------------------- > > Stack Frame Procedure Descriptor > >Flags: Base Register = FP, No Jacket, Native > > Procedure Entry: FFFFFFFF.8008EF40 SYS$QIOW_C > > Return address on stack = FFFFFFFF.80086FD8 > EXE$DASSGN_C+00198 > > > >Registers saved on stack > >------------------------ > >7FFA1EC0 00000000.00000020 Saved R2 > >7FFA1EC8 FFFFFFFF.85D3CAE0 Saved R3 EXE$CMODEXECX > >7FFA1ED0 FFFFFFFF.81193580 Saved R4 PCB > >7FFA1ED8 00000000.7FFA1F40 Saved R29 > > > >Regards, > > > >Derek... > > > _________________________________________________________________________ > 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, 1 Jun 1999 11:15:33 -0400 Message-ID: <4.1.19990601091822.00b9dce0@mehlhop.org> Date: Tue, 01 Jun 1999 09:18:41 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: RE: RWAST Processes In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 04:02 PM 6/1/99 +0100, you wrote: >Jim, > >Compaq have investigated and said that the processes appear to be waiting >for I/O completion from one of our disks (although this appears to be fine). >The first-level guy has escalated this and will get back to me. > >I was planning on waiting until I had more info from Compaq prior to logging >this with my TCPware supplier. Just thought I'd post a quick message on the >newsgroup in the meantime. Ok Good luck > >I'll let you know what Compaq come back with (and log a call if required). > >Derek... > >> -----Original Message----- >> From: Jim Mehlhop [SMTP:mehlhop@process.com] >> Sent: 01 June 1999 15:26 >> To: Info-TCPware@process.com >> Subject: Re: RWAST Processes >> >> This typically means that an IO device (the one being Deassigned) still >> has >> an IO outstanding. Have you heard back from DEC (Digital Enhanced Compaq) >> yet? >> >> Have you logged a call with us? >> >> Jim >> >> At 11:39 AM 6/1/99 +0100, you wrote: >> >Hi there, >> > >> >I've got a couple of processes hanging around in RWAST state. These are >> all >> >incoming telnet connections, and appear to be quite old (TCPware v5.3-3) >> > >> >I've logged a call with Compaq to get them to investigate the processes >> and >> >get back to me, but thought I'd post it here as well. >> > >> >Interestingly, the show call from SDA> shows the same return address for >> all >> >of the processes: >> > >> >SDA> show call >> > >> >Call Frame Information >> >---------------------- >> > Stack Frame Procedure Descriptor >> >Flags: Base Register = FP, No Jacket, Native >> > Procedure Entry: FFFFFFFF.8008EF40 SYS$QIOW_C >> > Return address on stack = FFFFFFFF.80086FD8 >> EXE$DASSGN_C+00198 >> > >> >Registers saved on stack >> >------------------------ >> >7FFA1EC0 00000000.00000020 Saved R2 >> >7FFA1EC8 FFFFFFFF.85D3CAE0 Saved R3 EXE$CMODEXECX >> >7FFA1ED0 FFFFFFFF.81193580 Saved R4 PCB >> >7FFA1ED8 00000000.7FFA1F40 Saved R29 >> > >> >Regards, >> > >> >Derek... >> >> >> _________________________________________________________________________ >> Jim Mehlhop, Support Engineer >> Process Software >> Mehlhop@process.com >> Phone 719-638-8448 >> Join Cauce to outlaw spam >> http://www.cauce.org/ >> >> _________________________________________________________________________ _________________________________________________________________________ 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, 1 Jun 1999 11:19:05 -0400 Subject: Re: RWAST Processes Message-ID: <1999Jun1.103227@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Jun 99 10:32:27 -0400 To: Info-TCPware@PROCESS.COM Derek: It would be useful to know what channels have I/O on them for these processes. SDA> SHOW PROC/CHANNEL would be useful. - Bernie Volz Process Software In article , Derek Fage writes: > Hi there, > > I've got a couple of processes hanging around in RWAST state. These are all > incoming telnet connections, and appear to be quite old (TCPware v5.3-3) > > I've logged a call with Compaq to get them to investigate the processes and > get back to me, but thought I'd post it here as well. > > Interestingly, the show call from SDA> shows the same return address for all > of the processes: > > SDA> show call > > Call Frame Information > ---------------------- > Stack Frame Procedure Descriptor > Flags: Base Register = FP, No Jacket, Native > Procedure Entry: FFFFFFFF.8008EF40 SYS$QIOW_C > Return address on stack = FFFFFFFF.80086FD8 EXE$DASSGN_C+00198 > > Registers saved on stack > ------------------------ > 7FFA1EC0 00000000.00000020 Saved R2 > 7FFA1EC8 FFFFFFFF.85D3CAE0 Saved R3 EXE$CMODEXECX > 7FFA1ED0 FFFFFFFF.81193580 Saved R4 PCB > 7FFA1ED8 00000000.7FFA1F40 Saved R29 > > Regards, > > Derek... ================================================================================ Archive-Date: Tue, 1 Jun 1999 11:31:36 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: RWAST Processes Date: Tue, 1 Jun 1999 16:30:14 +0100 MIME-Version: 1.0 Content-Type: text/plain SDA> show proc/channel Process index: 0021 Name: _NTA4: Extended PID: 204E0221 ----------------------------------------------------------- Process active channels ----------------------- Channel Window Status Device/file accessed ------- ------ ------ -------------------- 0010 00000000 DSA1: 0020 00000000 DSA1: 0030 8150DA80 DSA1:[EXSHARE_LIVE]FTSV_LICENCE_CHECK.EX E;18 0040 00000000 NTA4: 0050 81455340 DSA11:[SYSCOMMON.SYSLIB]SECURESHRP.EXE;1 (section file) 0060 00000000 NTA4: 0070 811E29C0 DSA11:[SYSCOMMON.SYSLIB]LIBOTS.EXE;1 (se ction file) 0080 811E3C00 DSA11:[SYSCOMMON.SYSLIB]DPML$SHR.EXE;1 ( section file) 0090 811CB680 DSA11:[SYSCOMMON.SYSEXE]DCL.EXE;2 (secti on file) 00A0 81180A80 DSA11:[SYSCOMMON.SYSLIB]DCLTABLES.EXE;22 7 (section file) Press RETURN for more. SDA> Process index: 0021 Name: _NTA4: Extended PID: 204E0221 ----------------------------------------------------------- Channel Window Status Device/file accessed ------- ------ ------ -------------------- 00B0 811E33C0 DSA11:[SYSCOMMON.SYSLIB]CMA$TIS_SHR.EXE; 1 (section file) 00C0 811E2540 DSA11:[SYSCOMMON.SYSLIB]LIBRTL.EXE;4 (se ction file) 00D0 811E4440 DSA11:[SYSCOMMON.SYSLIB]DECC$SHR.EXE;6 ( section file) 00E0 811E0E80 DSA11:[SYSCOMMON.SYSLIB]DEC$BASRTL.EXE;2 (section file) 00F0 811E2B80 DSA11:[SYSCOMMON.SYSLIB]LIBOTS2.EXE;1 (s ection file) 0100 8139E8C0 DSA2:[EXSHARE_EXSHARE]SDS_CLIENT_DATABAS E.DAT;29 > -----Original Message----- > From: volz@process.com [SMTP:volz@process.com] > Sent: 01 June 1999 15:32 > To: Info-TCPware@PROCESS.COM > Subject: Re: RWAST Processes > > Derek: > > It would be useful to know what channels have I/O on them for these > processes. SDA> SHOW PROC/CHANNEL would be useful. > > - Bernie Volz > Process Software > > In article , Derek Fage > writes: > > Hi there, > > > > I've got a couple of processes hanging around in RWAST state. These are > all > > incoming telnet connections, and appear to be quite old (TCPware v5.3-3) > > > > I've logged a call with Compaq to get them to investigate the processes > and > > get back to me, but thought I'd post it here as well. > > > > Interestingly, the show call from SDA> shows the same return address for > all > > of the processes: > > > > SDA> show call > > > > Call Frame Information > > ---------------------- > > Stack Frame Procedure Descriptor > > Flags: Base Register = FP, No Jacket, Native > > Procedure Entry: FFFFFFFF.8008EF40 SYS$QIOW_C > > Return address on stack = FFFFFFFF.80086FD8 > EXE$DASSGN_C+00198 > > > > Registers saved on stack > > ------------------------ > > 7FFA1EC0 00000000.00000020 Saved R2 > > 7FFA1EC8 FFFFFFFF.85D3CAE0 Saved R3 EXE$CMODEXECX > > 7FFA1ED0 FFFFFFFF.81193580 Saved R4 PCB > > 7FFA1ED8 00000000.7FFA1F40 Saved R29 > > > > Regards, > > > > Derek... ================================================================================ Archive-Date: Tue, 1 Jun 1999 19:18:10 -0400 Subject: RE: RWAST Processes Message-ID: <1999Jun1.184032@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Jun 99 18:40:32 -0400 To: Info-TCPware@PROCESS.COM In article , Derek Fage writes: > SDA> show proc/channel Derek: Thanks for the output. Kind of odd that it doesn't show one of the channels as BUSY (as that indicates I/O is outstanding on the device). Can't be of more help at the moment. Wait to hear what Compaq has to say. (The next option might also be to track down the QIOW argument list to see which channel the I/O is being requested on.) - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 2 Jun 1999 03:55:24 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: NETCU_GATEWAY Date: Wed, 2 Jun 1999 08:54:06 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, Is there a way to setup TCPware (v5.3-3) so add a cost to the default gateway ? The reason I ask is that we have a default gateway set that is a router address on an internal interface that we need at system startup, and whenever gated is not running. However, when GATED is running, we need it to install a different default gateway (attached to a different interface). Using NETCU show route, I cannot see where the metric is displayed. I thought that I had this working by using a static route in GATED that appeared to take priority over the default gateway when GATED started, but the other day one of our cluster members lost all connection via the GATED default gateway due to NETCU SHOW ROUTE displaying the initial default route above the GATED default route. My questions are: 1. What is the defauilt metric for the default gateway ? 2. Can this be changed ? 3. Can I ensure that a GATED static route with default gateway command takes priority when GATED is running ? Cheers, Derek... ================================================================================ Archive-Date: Wed, 2 Jun 1999 08:13:19 -0400 Sender: bryant@process.com Date: Wed, 2 Jun 1999 08:11:33 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D9057.FDA06A2E.8@process.com> Subject: RE: NETCU_GATEWAY Derek Fage writes: > >Hi there, > >Is there a way to setup TCPware (v5.3-3) so add a cost to the default >gateway ? > >The reason I ask is that we have a default gateway set that is a router >address on an internal interface that we need at system startup, and >whenever gated is not running. > >However, when GATED is running, we need it to install a different default >gateway (attached to a different interface). > >Using NETCU show route, I cannot see where the metric is displayed. > >I thought that I had this working by using a static route in GATED that >appeared to take priority over the default gateway when GATED started, but >the other day one of our cluster members lost all connection via the GATED >default gateway due to NETCU SHOW ROUTE displaying the initial default route >above the GATED default route. > >My questions are: > >1. What is the defauilt metric for the default gateway ? >2. Can this be changed ? >3. Can I ensure that a GATED static route with default gateway command takes >priority when GATED is running ? > >Cheers, > >Derek... TCPware does not maintain a metric for routes in the routing table. We do however allow for multiple default routes and have some dead gateway detection. With dead gateway detection, if we detect via ARP that a router might be down, we flag the route and change the order of the routes in the routing table, such that the next default route is used, and the one currently in use which we suspect is down is moved tot he end of the list. The first default route in the list is the only one actually in use at any given time. So, your analysis is correct of what happened. What I don't understand is why Gated would be down at any time. Is there an issue with the startup order that causes you to need to set one route before Gated is started? ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Wed, 2 Jun 1999 08:53:15 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NETCU_GATEWAY Date: Wed, 2 Jun 1999 13:52:11 +0100 MIME-Version: 1.0 Content-Type: text/plain Geoff, It was historical really - we had the default route in before we starting using GATED and the second interface. I was just interested in the way it worked (and if metrics were maintained in the routing map). I guess it'll be easier to just remove the NETCU_GATEWAY default route and leave it all to GATED. Cheers, Derek... > -----Original Message----- > From: Geoff Bryant [SMTP:bryant@process.com] > Sent: 02 June 1999 13:12 > To: Info-TCPware@process.com > Cc: bryant@process.com > Subject: RE: NETCU_GATEWAY > > Derek Fage writes: > > > >Hi there, > > > >Is there a way to setup TCPware (v5.3-3) so add a cost to the default > >gateway ? > > > >The reason I ask is that we have a default gateway set that is a router > >address on an internal interface that we need at system startup, and > >whenever gated is not running. > > > >However, when GATED is running, we need it to install a different default > >gateway (attached to a different interface). > > > >Using NETCU show route, I cannot see where the metric is displayed. > > > >I thought that I had this working by using a static route in GATED that > >appeared to take priority over the default gateway when GATED started, > but > >the other day one of our cluster members lost all connection via the > GATED > >default gateway due to NETCU SHOW ROUTE displaying the initial default > route > >above the GATED default route. > > > >My questions are: > > > >1. What is the defauilt metric for the default gateway ? > >2. Can this be changed ? > >3. Can I ensure that a GATED static route with default gateway command > takes > >priority when GATED is running ? > > > >Cheers, > > > >Derek... > > TCPware does not maintain a metric for routes in the routing table. We > do > however allow for multiple default routes and have some dead gateway > detection. > With dead gateway detection, if we detect via ARP that a router might be > down, > we flag the route and change the order of the routes in the routing table, > such > that the next default route is used, and the one currently in use which we > > suspect is down is moved tot he end of the list. The first default route > in > the list is the only one actually in use at any given time. > > So, your analysis is correct of what happened. What I don't understand > is why > Gated would be down at any time. Is there an issue with the startup order > that > causes you to need to set one route before Gated is started? > > ------------------------------------------------------------- > Geoff Bryant bryant@process.com > TCPware/Multinet Engineering > Process Software Corporation http://www.process.com/ > 959 Concord St. > Framingham, MA 01701 USA ================================================================================ Archive-Date: Wed, 2 Jun 1999 11:13:51 -0400 Message-ID: <37553C5B.8F63D5D7@cheerful.com> From: Jean-Marc Beaudoin Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: SSH and OpenVMS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 02 Jun 1999 14:14:56 GMT To: Info-TCPware@PROCESS.COM Good day, Is there an ssh (secure connection) package somewhere for OpenVMS? Regards, ================================================================================ Archive-Date: Wed, 2 Jun 1999 11:17:14 -0400 Message-ID: <4.1.19990602091837.00a2ab20@mehlhop.org> Date: Wed, 02 Jun 1999 09:20:18 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: SSH and OpenVMS In-Reply-To: <37553C5B.8F63D5D7@cheerful.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Yes there are a couple of packages out there. You may want to hit dajanews to look at the newsgroup VMS-SSH@alpha.sggw.waw.pl has info on ssh/ssl/fish etc Jim At 02:14 PM 6/2/99 +0000, you wrote: >Good day, > >Is there an ssh (secure connection) package somewhere for OpenVMS? > >Regards, > > _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Wed, 2 Jun 1999 16:48:34 -0400 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: SSH and OpenVMS Message-ID: <3755881f.524144494f47414741@radiogaga.harz.de> Date: Wed, 02 Jun 1999 21:38:07 +0200 Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Jean-Marc Beaudoin (percival@cheerful.com) wrote: : Is there an ssh (secure connection) package somewhere for OpenVMS? From: levitte@lp.se (Richard Levitte - VMS Whacker) Newsgroups: comp.os.vms Subject: Re: SSH on VMS Date: 31 May 1999 07:33:37 GMT scandora@cmt.anl.gov (Tony Scandora 630-252-7541) writes: > We are running VMS 6.2 and a similar vintage MultiNet. They have been > working nicely, but now we have to use SSH. What are our options? Client: http://www.free.lp.se/fish/ Server: http://kcgl1.eng.ohio-state.edu/~jonesd/ssh/ About the client (FISH), I'd wait a couple of days. I'm finishing the next version that will contain methods to at least create RSA keys. [End Quote] cu, Martin -- | Martin Vorlaender | VMS & WNT programmer VMS is today what | work: mv@pdv-systeme.de Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Thu, 3 Jun 1999 18:03:16 -0400 From: "Kenneth John Barclay" Reply-To: Info-TCPware@process.com Subject: UDP and OVMS Message-ID: Date: Fri, 4 Jun 1999 09:57:48 +1200 To: Info-TCPware@PROCESS.COM Does anyone know of a third party driver package that permits UDP transmission of over 1500 byte packets (the ability to fragment) on OpenVMS V6.2 for the Alpha 7XXX system???? It seems that DEC/Compaq only supports this under V7.X. Thanks in advance. ================================================================================ Archive-Date: Fri, 4 Jun 1999 08:17:25 -0400 Sender: bryant@process.com Date: Fri, 4 Jun 1999 08:15:11 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-MultiNet@process.com CC: Info-TCPware@process.com, bryant@process.com Message-ID: <009D91EA.D422FB68.66@process.com> Subject: RE: UDP and VMS "Kenneth John Barclay" writes: > >Does anyone know of a third party driver package that permits UDP >transmission of over 1500 byte packets (the ability to fragment) on OpenVMS >V6.2 for the Alpha 7XXX system???? It seems that DEC/Compaq only supports >this under V7.X. > >Thanks in advance. Since you posted to both info-multinet and info-tcpware, I am replying to both... Anyway, certainly TCPware and Multinet will allow UDP packets greater than 1500 bytes. One thing to be aware of is that you may need to modify the send and receive buffer sizes using the SO_SNDBUF and SO_RCVBUF socket options. Note that we support VMS V6.2 for Alpha in both products. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 7 Jun 1999 11:53:10 -0400 Date: Mon, 07 Jun 1999 11:44:33 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V533P030 To: TCPware-Announce@PROCESS.COM Message-ID: <01JC48VQLJMA002LQ0@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V533P030 Description: Fix twisted pair ethernet and deleting permanent NT= A Release date: 7-JUN-1999 Versions: 5.3-3 ftp://ftp.process.com/support/53_3/drivers_v533p030.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 for TCPware Version 5.3-3 May 20, 1999 Copyright =A9 1999 Process Software Corporation This patch kit provides new versions of the following driver(s): BGDRIVER INETDRIVER IPDRIVER NTDRIVER The following changes have been made: BGDRIVER - D/E 2298 - Modify behaviour of IO$_DEACCESS - D/E 3509 - Modified to allow DCL/Perl scripts to= work properly under the Netscape FastTrack= web server. INETDRIVER - D/E 339 - Correct the output of an extra f= or output from REXEC IPDRIVER - D/E 2213 - Fix routine which derives largest MTU= of all physical interfaces. This is us= ed by TCP to set the MSS advertised at conn= ection establishment. - D/E 2453 - EWA twisted pair Ethernet controllers= with the cable removed would hang TCPware = during startup. This problem has been corre= cted. NTDRIVER - DE 3330: Drop any received data when closing. DE 1537: Permanent NTA /w CLOSE_DASSGN cannot b= e deleted. NOTE: You must reboot your system after installing this patch in or= der 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) bac= k 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 [End of ECO announcement] ================================================================================ Archive-Date: Mon, 7 Jun 1999 17:54:17 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8601413722@lespaul.process.com> From: Lauren Maschio Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: Technical Advisory Council Date: Mon, 7 Jun 1999 17:52:14 -0400 MIME-Version: 1.0 Content-Type: text/plain Process Software is forming a Technical Advisory Council. The goal of the council is to have our customers actively participate in the technical direction of Process Software's OpenVMS products. This will provide an excellent opportunity to share your ideas with the key design architects of MultiNet and TCPware, and gain insight into future developments and product roadmaps that will affect your networks. As a participant in the Technical Advisory Council, we will be scheduling 1-2 meetings per year. Ongoing communications and developements with the council will be done through the web and e-mail. Process Software's kick-off meeting of the TCP/IP for OpenVMS Technical Advisory Council is on Monday June 14th at the Biltmore Hotel in Providence, RI, from 6:30-8:30pm. We choose to meet in Providence since many of our customers are attending Compaq's DECUS Providence event from June 12-17th. If you are interested in joining the Technical Advisory Council and attending our kick-off dinner meeting, please send an e-mail to maschio@process.com for more information. -------------------------------------------- Lauren Maschio Senior Product Manager Process Software 959 Concord Street Framingham, MA 01701-4682 (508) 626-7525 -------------------------------------------- ================================================================================ Archive-Date: Thu, 10 Jun 1999 09:03:05 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Replacing the 'From:' string in SMTP Date: Thu, 10 Jun 1999 13:51:13 +0100 Message-ID: <7jocc2$9qu$1@mailgate.liffe.com> To: Info-TCPware@PROCESS.COM We have a single TCPware SMTP mail server on our network (a VAX running OpenVMS V5.5-2 and - horror - TCPware V5.0-3B). Mail gets sent from this SMTP server to a Solaris system running SENDMAIL and then on to the outside world. When a job on another OpenVMS system wants to send mail out it sends it to XXXXXX::smtp%"whoever@somewhere.com" where XXXXXX is the nodename of the SMTP system. All well & good... Our main production systems are a cluster of 4 VAX systems running OpenVMS V6.2 with a DECnet cluster alias defined. We have one particular batch job (that always runs on the same node within the cluster) that sends mail to an external person. Unfortunately, this mail appears to get bounced by the receiving server at the remote site with a "Sender domain must exist" message. At this stage though, the FROM: message appears as "{vms-username}%{cluster-alias}.decnet"@{smtp-system}.domain.com An example would be "SYSTEM%ALIAS.decnet"@server.domain.com From what we can gather the remote system appears to be trying to send something back (a receipt ?) and is choking on the address. Is there any way within SMTP that we can "substitute" a different string for what appears in this 'From:' line ? Failing that, has anybody else experienced this kind of thing & found a solution ? Thanks for any help, -Andy ================================================================================ Archive-Date: Thu, 10 Jun 1999 19:19:13 -0400 From: panderson@genicom.com Reply-To: Info-TCPware@process.com Subject: DCPS to officially support TCPware Date: Thu, 10 Jun 1999 20:58:16 GMT Message-ID: <7jp8t3$srj$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Compaq's PostScript printing software, DECprint Supervisor (DCPS) for OpenVMS will, with our next release, officially support TCPware as well as TCP/IP Services and MultiNet. This release will be called DCPS V1.7-1; we'll support TCPware V5.3 and later. We made no changes to DCPS to support TCPware. We had a problem with the Compaq Laser Printer LN32 that required us to specify NETCU START /TCP /NOPATH_MTU_DISCOVERY but it's being fixed in the printer. The TCPware patch DRIVERS_V533P020 also solves the problem. I'm sure some of you are already running DCPS over TCPware, but I'd just like to officially welcome you into the fold! Paul -- Paul Anderson (panderson@genicom.com) DCPS Engineering GENICOM Corporation, Boxborough MA Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ================================================================================ Archive-Date: Sun, 13 Jun 1999 11:10:28 -0400 From: "Brian Steele" Reply-To: Info-TCPware@process.com Subject: TCPWare 5.3, VMS 7.1, MSP2.0? Date: Mon, 7 Jun 1999 10:51:31 -0400 Message-ID: <7jgmcn$3bj1@col3.caribsurf.com> To: Info-TCPware@PROCESS.COM Is there any way to configure TCPWare 5.3 on a VAX/VMS box running 7.1 on a private network so that a logged on user can access the Internet via our proxy server (running MSP2.0)? Brian Steele ================================================================================ Archive-Date: Sun, 13 Jun 1999 12:05:50 -0400 Sender: schreiber@process.com Date: Sun, 13 Jun 1999 12:03:33 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: info-tcpware@process.com, info-multinet@process.com Message-ID: <009D991D.392C5A61.5@process.com> Subject: Upcoming DECUS Providence Sessions Process Software employees will be presenting quite a few sessions in Providence next week. For those that are there and interested, here's a list! - Domain Name System Introduction and Overview (IN109) Mon 8:00-9:20 Room 552A Introduction Jeff Schreiber - Implementing DNS Dynamic Update in Applications (IN110) Mon 9:30-10:50 Room 552A Advanced Jeff Schreiber - DHCP Failover Protocol Dynamic Address Management (IN106) Mon 2:00-3:20 Room 551B Intermediate Steve Gonczi - Case Study in Directory Enabling an Application (IN108) Mon 3:30-4:50 Room 551B Intermediate Andy Bennett - Benefits of Directory-Centric IP Resource Mgmt. (NE103) Mon 3:30-4:50 Room 555B Introduction Steve Chirokas - Implementing DHCP Overview (EN120) Tues 9:30-10:50 Room 555B Intermediate Bob Moore - Managing IP Address Tools in Enterprise Networks (NE106) Tue 2:00-3:20 Room 555B Introduction Steve Chirokas ================================================================================ Archive-Date: Sun, 13 Jun 1999 16:58:57 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: TCPWare 5.3, VMS 7.1, MSP2.0? Date: 13 Jun 1999 22:55:29 +0100 Message-ID: <37641ac1.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <7jgmcn$3bj1@col3.caribsurf.com>, "Brian Steele" writes: >Is there any way to configure TCPWare 5.3 on a VAX/VMS box running 7.1 on a >private network so that a logged on user can access the Internet via our >proxy server (running MSP2.0)? This is IMHO not a TCPware problem. Use a real (telnet) proxy instead of M$. -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Wed, 16 Jun 1999 07:37:06 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: Nameserver Y2K issues Date: Wed, 16 Jun 1999 12:33:33 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi, I'm doing some testing on an AlphaServer 800 by setting the date forward to the year 2000, but seem to have run across a problem with DNS. The server is running TCPware 5.3-3 and is configured as a secondary nameserver (Primary is another OpenVMS TCPware system). The problem is that nslookup and all DNS lookups appear to fail. The NAMESERVER.LOG log file has some entries about secondary zones expiring (see below): %%%%%%%%%%%% NAMED 2-JAN-2000 11:10:27.51 %%%%%%%%%%%% %TCPWARE_NAMED-I-STALE, secondary zone "itexhld.com" expired %%%%%%%%%%%% NAMED 2-JAN-2000 11:12:13.19 %%%%%%%%%%%% %TCPWARE_NAMED-I-STALE, secondary zone "150.202.194.in-addr.arpa" expired Any ideas how I can work around this ? Derek... ================================================================================ Archive-Date: Wed, 16 Jun 1999 10:03:32 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86015C1E7C@lespaul.process.com> From: Mohammed Boukantar Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Nameserver Y2K issues Date: Wed, 16 Jun 1999 10:01:04 -0400 MIME-Version: 1.0 Content-Type: text/plain > > Hi, > > I'm doing some testing on an AlphaServer 800 by setting the > date forward to > the year 2000, but seem to have run across a problem with DNS. > > The server is running TCPware 5.3-3 and is configured as a secondary > nameserver (Primary is another OpenVMS TCPware system). > > The problem is that nslookup and all DNS lookups appear to fail. The > NAMESERVER.LOG log file has some entries about secondary > zones expiring (see > below): > > %%%%%%%%%%%% NAMED 2-JAN-2000 11:10:27.51 %%%%%%%%%%%% > %TCPWARE_NAMED-I-STALE, secondary zone "itexhld.com" expired > > > %%%%%%%%%%%% NAMED 2-JAN-2000 11:12:13.19 %%%%%%%%%%%% > %TCPWARE_NAMED-I-STALE, secondary zone > "150.202.194.in-addr.arpa" expired Make sure that the Serial number, on both zone files at the primary, is greater than that of the secondary zone files for itexhld.com and 150.202.194.in-addr.arpa. Thank you, ====================== Mohammed Boukantar 800-722-7770 ext. 382 Process Software Corp. boukantar@process.com http://www.process.com ====================== ================================================================================ Archive-Date: Wed, 16 Jun 1999 10:22:48 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Nameserver Y2K issues Date: Wed, 16 Jun 1999 15:11:26 +0100 MIME-Version: 1.0 Content-Type: text/plain Both serial numbers are in sync (due to the fact that it is working currently). Are you saying that after rolling the test box date forward that I should increment the serial numbers on the primary box and then restart dns on the secondary ? Cheers, Derek... > -----Original Message----- > From: Mohammed Boukantar [SMTP:boukantar@process.com] > Sent: 16 June 1999 15:01 > To: 'Info-TCPware@process.com' > Subject: RE: Nameserver Y2K issues > > > > > Hi, > > > > I'm doing some testing on an AlphaServer 800 by setting the > > date forward to > > the year 2000, but seem to have run across a problem with DNS. > > > > The server is running TCPware 5.3-3 and is configured as a secondary > > nameserver (Primary is another OpenVMS TCPware system). > > > > The problem is that nslookup and all DNS lookups appear to fail. The > > NAMESERVER.LOG log file has some entries about secondary > > zones expiring (see > > below): > > > > %%%%%%%%%%%% NAMED 2-JAN-2000 11:10:27.51 %%%%%%%%%%%% > > %TCPWARE_NAMED-I-STALE, secondary zone "itexhld.com" expired > > > > > > %%%%%%%%%%%% NAMED 2-JAN-2000 11:12:13.19 %%%%%%%%%%%% > > %TCPWARE_NAMED-I-STALE, secondary zone > > "150.202.194.in-addr.arpa" expired > > Make sure that the Serial number, on both zone files at the primary, is > greater than that of the secondary zone files for itexhld.com and > 150.202.194.in-addr.arpa. > > > > > Thank you, > ====================== > Mohammed Boukantar > 800-722-7770 ext. 382 > Process Software Corp. > boukantar@process.com > http://www.process.com > ====================== ================================================================================ Archive-Date: Thu, 17 Jun 1999 17:20:23 -0400 Sender: goatley@triton.process.com Return-Path: Date: Wed, 16 Jun 1999 15:07:07 -0400 (EDT) From: Gary Reynolds Reply-To: Info-TCPware@process.com To: TCPware Info Subject: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET to Alpha fails Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I've been trying to implement cross-platform connectivity since I got TCPware working. I will be updating shortly. One of the areas that I wanted to investigate was Alpha access via TELNET rather than the somewhat awkward way we do it thru PC COM ports using KERMIT. On the PATHWORKS-32 cd is a version of PowerTerm that I wanted to check Alpha access thru TELNET. The full details are below in a message, I at first incorrectly ascribed to the PowerTerm product - but as I have had time to look at it, appears to result from some mis-configuration of TCPware-TELNET. Let me know what you think and I thank you beforehand for your assistance. One other possibility as I'm thinking about it is the configuration of our Datability terminal servers ... Gary greynold@waynesburg.edu > > MESSAGE: Compaq/DEC Alpha server 2100 4/233 Open VMS 6.2 1H-2 using > TCPware 5.2-3 IP stack to access LAN Network connected to Internet > using SCO Unixware 2.12 server. > Local Alpha network is running DecNet Phase IV / LAT services. > > P-166 PC Client, WIN 95 OSR-2, 16 mb RAM, IP-address assigned to the > client static. TCP/IP Winsock 1.2. > Network card 3-COM EtherNIC III TP-0 w/PNP > > Evaluating PowerTerm V4.00.44 from PATHWORKS 32 CD > I've also downloaded the current DEMO version with the same results > > Installation without error - Attempts to connect > to Alpha hostname errors out with "unable > to connect to host name". In fact, attempts to > access main Unix server also errors out. > With the current DEMO PowerTerm, I am able to TELNET to Unix server, but not Alpha. From the Alpha-TCPware, I can also telnet to the Unix server. > > As the PowerTerm Installation guide had suggested, > I installed the BASE PW-32 with NO LAT or DecNet > support - as access was to DecNet is only Telnet via TCP/IP. > > PowerTerm - COM1 port access works OK!, as I have a Serial > access line installed on my PC but the main reason > I'm investigating is to remove the need for a > separate Serial line to access Alpha. > > I had previously installed ExCursion from PW-32 > CD and while I had a little difficulty tailoring, > it did finally and is working for me. > I hope you can help, as this looks real good if we can get the connection setup worked out. The more I think about it, though, the more suspicious I'm becoming of the terminal servers impact on this. thanks, gary > > EMAIL = greynold@waynesburg.edu > > phone = 724-852 3328 > > Company Name = Waynesburg Collge > > Company Position = Director, I.S. > > street = 51 W. College St. > > street 2 = > > city = Waynesburg > > state = PA > > zip = 15370 > > Emulation = VT 420 > > Connection = TCP/IP, TELNET > ================================================================================ Archive-Date: Thu, 17 Jun 1999 17:20:41 -0400 Sender: goatley@triton.process.com Return-Path: Date: Thu, 17 Jun 1999 10:13:15 -0400 (EDT) From: Gary Reynolds Reply-To: Info-TCPware@process.com To: TCPware Info Subject: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET to Alpha fails Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ... excerpted from my last mail ---------- Forwarded message ---------- Date: Wed, 16 Jun 1999 15:07:07 -0400 (EDT) From: Gary Reynolds To: TCPware Info Subject: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET to Alpha fails Hello, I've been trying to implement cross-platform connectivity since I got TCPware working. I will be updating shortly. One of the areas that I wanted to investigate was Alpha access via TELNET rather than the somewhat awkward way we do it thru PC COM ports using KERMIT. On the PATHWORKS-32 cd is a version of PowerTerm that I wanted to check Alpha access thru TELNET. The full details are below in a message, I at first incorrectly ascribed to the PowerTerm product - but as I have had . . for your assistance. One other possibility as I'm thinking about it is the configuration of our Datability terminal servers ... [ This appears to be the main difficulty I was encountering . ] [ I believe I need to set the terminal servers up to support Reverse TELNET ] [ for incoming login connect and have begun exploring requirements for that ] [ Any insights on the VMS/Terminal Server side would be appreciated, as I ] [ still don't have this configured properly to support VMS Telnet login. ] Gary greynold@waynesburg.edu ================================================================================ Archive-Date: Fri, 18 Jun 1999 08:54:28 -0400 Sender: bryant@process.com Date: Fri, 18 Jun 1999 08:51:55 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D9CF0.47FFBC16.3025@process.com> Subject: RE: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET to Alpha fails Hopefully I understand what you are doing since I am not familiar with what you are doing, but I assume you have loaded a telnet client on your PC and you are trying to connect up to a tcpware system. It also sounds like you can succesfully reach a Unix system. If that is correct, there are two things to attempt: - NETCU SHOW SERVICE so we can see if the telnet server us set up - Go to the Unix system and try to telnet in from there This will hopefully give some clues. Gary Reynolds writes: > > >... excerpted from my last mail > >---------- Forwarded message ---------- >Date: Wed, 16 Jun 1999 15:07:07 -0400 (EDT) >From: Gary Reynolds >To: TCPware Info >Subject: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET to Alpha fails > >Hello, > > I've been trying to implement cross-platform connectivity since I got >TCPware working. I will be updating shortly. One of the areas that >I wanted to investigate was Alpha access via TELNET rather than the >somewhat awkward way we do it thru PC COM ports using KERMIT. On the >PATHWORKS-32 cd is a version of PowerTerm that I wanted to check >Alpha access thru TELNET. The full details are below in a message, I at >first incorrectly ascribed to the PowerTerm product - but as I have had >. >. >for your assistance. One other possibility as I'm thinking about it is >the configuration of our Datability terminal servers ... > >[ This appears to be the main difficulty I was encountering . ] >[ I believe I need to set the terminal servers up to support Reverse TELNET ] >[ for incoming login connect and have begun exploring requirements for that ] >[ Any insights on the VMS/Terminal Server side would be appreciated, as I ] >[ still don't have this configured properly to support VMS Telnet login. ] > >Gary >greynold@waynesburg.edu ================================================================================ Archive-Date: Fri, 18 Jun 1999 11:18:26 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: Purveyor Query Date: Fri, 18 Jun 1999 16:14:46 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, I'd like to find out if it is possible to modify my Purveyor Wenserver (2.0) so that when user authentication fails I can redirect the server to another page instead of displaying the standard "Unauthorized -- authentication failed. HTTP status code: 401" message. Regards, Derek... ================================================================================ Archive-Date: Fri, 18 Jun 1999 12:53:02 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: Nameserver Y2K issues Date: 16 Jun 1999 14:03:48 +0100 Message-ID: <376792a4.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article , Derek Fage writes: >I'm doing some testing on an AlphaServer 800 by setting the date forward to >the year 2000, but seem to have run across a problem with DNS. Which seems to indicate, that the system is normally connected to a network. And a y2k test is normally run in a standalone fashion. Right ? >The server is running TCPware 5.3-3 and is configured as a secondary >nameserver (Primary is another OpenVMS TCPware system). > >The problem is that nslookup and all DNS lookups appear to fail. The >NAMESERVER.LOG log file has some entries about secondary zones expiring (see >below): >[snip] >Any ideas how I can work around this ? The DNS server seems to not get any connection to the Prim DNS server and the locally (as files) stored database is after the date change obviously out of the valid time range. 1.) Restore the connection to the Prim DNS server so that the Sec DNS server could check the zone and find out, that it is still valid (and thus modifying the date of the local database files). Or 2.) Change the creation date of the local DNS files (in TCPWARE_NAMED_ROOT:) to the current date (eg. edit it don't change anything and store it back) and restart the local DNS server (@TCPWARE:RESTART DNS) -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Sat, 19 Jun 1999 09:40:47 -0400 Date: Wed, 05 May 1999 10:45:46 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: TELNET_V533P020 To: TCPware-Announce@PROCESS.COM Message-ID: <01JAU37GTDB6002735@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: TELNET_V533P020 Description: TN3270 fix for displaying data Release date: 5-MAY-1999 Versions: 5.3-3 ftp://ftp.process.com/support/53_3/telnet_v533p020.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. ----------------------------------------------------------- TELNET Patch kit (revision 2.0) for TCPware version 5.3-3 16-Apr-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of TELNET for TCPware for OpenVMS. This patch is applicable to TCPware 5.2-3 or higher on all the supported version of VAX/VMS and OpenVMS. The following change has been made: (1) When connecting to remote IBM host with IP stack version 3.1 through Digital's Altavista Firewall (Digital Unix version) via transparent telnet proxy server, telnet option was not properly negotiated and did not properly turn into TN3270 mode. This problem is fixed. (2) When connecting to IBM host in TN3270 mode, sometimes screens were not displayed until the user provided input. This has been corrected. (D/E 2338) The old version of TELNET will be renamed to TCPWARE_COMMON:[TCPWARE]TELNET.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE_COMMON:[TCPWARE]TELNET.EXE [End of ECO announcement] ================================================================================ Archive-Date: Mon, 21 Jun 1999 10:45:14 -0400 Date: Mon, 21 Jun 1999 10:34:17 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: IMAP_V533P010 To: TCPware-Announce@PROCESS.COM Message-ID: <01JCNQIGC9760001E4@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: IMAP_V533P010 Description: Numerous IMAP server fixes Release date: 21-JUN-1999 Versions: 5.3-3 ftp://ftp.process.com/support/53_3/imap_v533p010.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. ------------------------------------------------------------------------- IMAP Patch kit (revision 1.0) for TCPware version 5.3-3 14-Jun-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of IMAP for TCPware for OpenVMS. It is applicable to TCPware version 5.3-3 and all supported versions of OpenVMS. The following changes have been made: 1) The server has been upgraded to the IMAP4rev1 v11.241 server. 2) The IMAP server processes are no longer reused, as an attempt to reduce the occurance of "out of free storage" errors. !!!!IMPORTANT!!!! !!!!IMPORTANT!!!! The value of PGFLQUOTA for the SYSTEM account should be set to at least 50000 on VAX systems and 75000 on Alpha systems. This is due to a memory leak in the VMS MAILSHR shareable library that will occasionally cause an IMAP process to abort with an "out of free storage" error. Note that increasing the PGFLQUOTA parameter may require increasing the size of the system pagefiles. In addition, on VAX systems, it may be necessary to increase the value of the sysgen parameter VIRTUALPAGECNT. 3) On certain IMAP server aborts due to memory allocation failures, the VMS return error was not being logged. 4) If some RFC822 headers lines exceeded 255 bytes, one of the following could occur: - An IMAP server ACCVIO. - A "message not found" error returned to the IMAP client. - An error that contains no text returned to the IMAP client. 5) The IMAP server did not append the domain name to addresses containing only DECnet-style addresses. 6) The IMAP server would occasionally hang in a call to DECC$FPUT. 7) The IMAP server would generate an access violation when logging in as a username that did not have an entry in the system-wide VMSMAIL_PROFILE.DATA file (i.e, the user had not run MAIL yet). 8) Occasional access violations in the server caused deleted messages to end up in the WASTEBASKET folder and not get purged. 9) Miscellaneous other problems not related to customer defects have been corrected. The old version of IMAPD.EXE will be renamed to TCPWARE:IMAPD.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE:IMAPD.EXE [End of ECO announcement] ================================================================================ Archive-Date: Mon, 21 Jun 1999 11:06:31 -0400 Sender: goatley@triton.process.com Return-Path: From: "Carl G. Cioffi" Reply-To: Info-TCPware@process.com To: Subject: RE: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET to Alpha Date: Mon, 21 Jun 1999 09:59:55 -0400 Message-ID: <000201bebbee$576bb680$13faff0a@carl.splusnet> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: Why would you be setting up Reverse TELNET when connecting to a TELNET server from a PC which I assumed is connected via network? The terminal server doesn't have anything to do with the TELNET connection if this is the case. BTW: I use SmartTerm from Persoft and it works great. > -----Original Message----- > From: goatley@triton.process.com [mailto:goatley@triton.process.com]On > Behalf Of Gary Reynolds > Sent: Thursday, June 17, 1999 10:13 AM > To: TCPware Info > Subject: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET to Alpha > fails > > > > ... excerpted from my last mail > > ---------- Forwarded message ---------- > Date: Wed, 16 Jun 1999 15:07:07 -0400 (EDT) > From: Gary Reynolds > To: TCPware Info > Subject: TCPware 5.2-3 - PATHWORKS-32 CD and PowerTerm : TELNET > to Alpha fails > > Hello, > > I've been trying to implement cross-platform connectivity since I got > TCPware working. I will be updating shortly. One of the areas that > I wanted to investigate was Alpha access via TELNET rather than the > somewhat awkward way we do it thru PC COM ports using KERMIT. On the > PATHWORKS-32 cd is a version of PowerTerm that I wanted to check > Alpha access thru TELNET. The full details are below in a message, I at > first incorrectly ascribed to the PowerTerm product - but as I have had > . > . > for your assistance. One other possibility as I'm thinking about it is > the configuration of our Datability terminal servers ... > > [ This appears to be the main difficulty I was encountering . ] > [ I believe I need to set the terminal servers up to support > Reverse TELNET ] > [ for incoming login connect and have begun exploring > requirements for that ] > [ Any insights on the VMS/Terminal Server side would be > appreciated, as I ] > [ still don't have this configured properly to support VMS Telnet > login. ] > > Gary > greynold@waynesburg.edu > > > > ================================================================================ Archive-Date: Mon, 21 Jun 1999 14:57:34 -0400 Subject: Re: Purveyor Query Message-ID: <1999Jun21.143026@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 21 Jun 99 14:30:26 -0400 To: Info-TCPware@PROCESS.COM In article , Derek Fage writes: > Hi there, > > I'd like to find out if it is possible to modify my Purveyor Wenserver (2.0) > so that when user authentication fails I can redirect the server to another > page instead of displaying the standard "Unauthorized -- authentication > failed. HTTP status code: 401" message. > > Regards, > > Derek... *** WARNING !!! The following information is being provided "as is" for Purveyor for OpenVMS Version 2.0 and later. No support is given for these features. If these features are used and you have a problem with Purveyor, disable use of these features and retest before reporting the problem. These features are undocumented and unsupported. ------------------------------------------------------------------------ Purveyor now supports error processing documents. Instead of returning the fixed (internal) error, Purveyor can instead return a customized message. Basiscally, Purveyor "redirects" to the error document, if configured. This document may be a .HTML, .HTP, or other file or CGI. The document that is specified must be GLOBALLY accessible by all virtual servers for that database configuration. If you use a file of /error/404error.html (for example), then there must be an error directory in each virtual servers default data directory! (Or, a virtual path of "error" configured.) If the indicated document can not be found or accessed, that error is returned to the user (ie, recursion on error handling is not allowed). The log file will always log the ORIGINAL status. NOTICE: This is *NOT* documented and this support can NOT be configured via RSM. This support hasn't been throughly tested and there may be problems in using it. WARNING: Do not use a DLL that requests deferred processing! This is not supported and will cause severe problems (probably ACCVIOs). NOTICE: If a CGI or DLL is run, it can get the original document URL from the WWW_REQUEST_LINE environment variable. No error code is passed to it (that can be solved by having a separate CGI/DLL for each error code). The key under which these entries are stored is: SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments And, the values under this key are as follows: Value xx Name: 404 Type: REG_SZ Data: /~error/notfound.html where Name is the error code and Data is the new URL (use of a virtual path is recommended especially when using the virtual server support). You can set these entries up as follows: $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch $ UTILITY UPDATE database - "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments" - "error-code" "error-URL" "REG_SZ" where arch is either VAX or AXP and database is the configuration database file's name. Note that the quotes, where shown above, are required. ------------------------------------------------------------------------ Three special parameters are now supported in the configuration database. Please note that NO configuration (RSM) is provided for these parameters and they should not normally be needed. However, in some special circumstances, there may be a reason to tune them. To tune these values, one must manually add them (using a text editor) to the configuration database file. You can also add these using the following sequence: $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch $ UTILITY UPDATE database - "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - "SO_BACKLOG" 256 "REG_DWORD" $ UTILITY UPDATE database - "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - "SO_SNDBUF" 16384 "REG_DWORD" $ UTILITY UPDATE database - "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - "SO_RCVBUF" 16384 "REG_DWORD" where arch is either VAX or AXP and database is the configuration database file's name. Note that the quotes, where shown above, are required. They are SYSTEM\CurrentControlSet\Services\Purveyor\Parameters: Value xx Name: SO_BACKLOG Type: REG_DWORD Data: 256 Value xx+1 Name: SO_SNDBUF Type: REG_DWORD Data: 16384 Value xx+2 Name: SO_RCVBUF Type: REG_DWORD Data: 16384 SO_BACKLOG allows one to set the connection backlog limit. This values is passed to the TCP/IP implementation to set the connection backlog. By default, Purveyor uses 256. SO_SNDBUF and SO_RCVBUF allows one to set the socket send and receive buffer limits (see setsockopt, SO_SNDBUF and SO_RCVBUF for complete details). By default, Purveyor uses 16384 for each of these. Reasons for wanting to tune these values could include: SO_BACKLOG If a TCP/IP implementation does not allow (and does not silently ignore) a value larger than its backlog limit. SO_SNDBUF/SO_RCVBUF To reduce the potential buffer space needed on a system for HTTP connections. With the 16384 default, having lots of slow or hung connections can result in significant buffer usage. Reducing these values can help avoid this at a decrease in network throughput. This is especially a consideration for TCP/IP Services for OpenVMS. ================================================================================ Archive-Date: Thu, 24 Jun 1999 12:12:40 -0400 Date: Thu, 24 Jun 1999 17:08:47 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: TCPware V5.3-3 and Pathworks V5.0F To: info-tcpware@process.com Message-ID: <99Jun24.171138bst.17934@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN Hi, This is our current production environment. OpenVMS V7.1-h1 Alpha TCPware V5.2-3 Pathworks V5.0F For reasons of Y2K compliance we are planning to upgrade to TCPware V5.3-3. Is anyone running this configuration? Are there any known problems with this combination? Many thanks /Steve ================================================================================ Archive-Date: Thu, 24 Jun 1999 12:24:29 -0400 Sender: goatley@triton.process.com Return-Path: Date: Thu, 24 Jun 1999 17:10:40 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: Re: TCPware V5.3-3 and Pathworks V5.0F In-Reply-To: To: info-tcpware@process.com Message-ID: <99Jun24.171310bst.17953@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN Sorry. the majority of our clients are NT workstation 4.0 SP4. Thanks again.. ================================================================================ Archive-Date: Thu, 24 Jun 1999 15:27:14 -0400 Date: Thu, 24 Jun 1999 20:25:41 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: Upgrade to TCPware V5.3-3 To: info-tcpware@process.com Message-ID: <99Jun24.202612bst.17934@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN OpenVMS V7.1-h1 Alpha I am planning to upgrade to TCPware V5.3-3. I was planning to install the following patches DNS_MAIN_V533P012 DRIVERS_V533P030 I realise that the drivers patch is a prerequisite for upgrade to OpenVMS V7.2. Is this compatible with V7.1? Just one less thing not to forget when I do upgrade to V7.2. TIA /Steve ================================================================================ Archive-Date: Thu, 24 Jun 1999 15:40:20 -0400 Message-ID: <4.1.19990624133608.00c09520@mehlhop.org> Date: Thu, 24 Jun 1999 13:36:20 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: Upgrade to TCPware V5.3-3 In-Reply-To: <99Jun24.202612bst.17934@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:25 PM 6/24/99 +0100, you wrote: >OpenVMS V7.1-h1 Alpha > >I am planning to upgrade to TCPware V5.3-3. > >I was planning to install the following patches > >DNS_MAIN_V533P012 >DRIVERS_V533P030 > >I realise that the drivers patch is a prerequisite for >upgrade to OpenVMS V7.2. Is this compatible with V7.1? Yes > >Just one less thing not to forget when I do upgrade to V7.2. > >TIA > >/Steve _________________________________________________________________________ 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, 24 Jun 1999 15:53:21 -0400 Message-ID: <54F85D7F6DE2D01184EF0000F804953501889895@MAIL04> From: "Senulis, Joseph A" Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: Flag pages in TCPware 5.3-2 Date: Thu, 24 Jun 1999 14:57:28 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi all, I have a user that would like to use flag (not banner) pages in LPS for each job, but when we do that with duplex forms, the first page of the file starts on the back side of the flag page. Remaining files in the job do start on the first side of a sheet of paper, even if a page must be skipped. I tried checking the only FAQ web page that refers to LPS: http://triton.process.com/support/tcpware/faqs/lps001.htp but it was blank and was supposed to refer to banner pages, not flag pages. I have tried a number of FORM, PRINT and PCL options and printing to an HP4M and an HP5si, without success. Before I waste more time hacking, does anyone know how to do this properly? We are running VMS 7.1 and TCPware 5.3-2. Thanks in advance. --Joe Joseph Senulis Technical Support Specialist BEITA ET/8 Wisconsin Department of Natural Resources 101 South Webster Street, Box 7921 Madison, Wisconsin 53707-7921 608-266-0853 senulj@dnr.state.wi.us ================================================================================ Archive-Date: Sat, 26 Jun 1999 02:56:58 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: TCPware V5.3-3 and Pathworks V5.0F Date: 24 Jun 1999 18:30:51 +0100 Message-ID: <37725d3b.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <99Jun24.171138bst.17934@gate.bgep.co.uk>, Steve Wakelin writes: >This is our current production environment. > >OpenVMS V7.1-h1 Alpha >TCPware V5.2-3 >Pathworks V5.0F > >For reasons of Y2K compliance we are planning to upgrade to >TCPware V5.3-3. > >Is anyone running this configuration? >Are there any known problems with this combination? Can't comment on V7.1-1H2 with TCPware but on V7.1 we had no problems with PWRK V5.0F caused by TCPware. We had a lot of troubles, but they were related to V5.0F (LM2 limitations), to PATHWORKS in general (crashing, loosing sync to UAS, ...). -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Sat, 26 Jun 1999 02:57:07 -0400 From: cousera@my-deja.com Reply-To: Info-TCPware@process.com Subject: Re: Replacing the 'From:' string in SMTP Date: Thu, 24 Jun 1999 20:57:34 GMT Message-ID: <7ku63o$h4a$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM In article <7jocc2$9qu$1@mailgate.liffe.com>, "Andy Williams" wrote: > 2 things you can try: 1. When setting up smtp (@cnfnet smtp) one of the questions is what to use as the from domain. What you put in there will override the default. 2. Use the alias feature of netcu. NETCU> ADD ALIAS/OUTGOING XX YY This will replace the from address with whatever you define here. Hope that helps, Lynn. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ================================================================================ Archive-Date: Sun, 27 Jun 1999 08:59:17 -0400 Message-ID: <3775F5CB.15A416E3@SMTP.DeltaTel.RU> Date: Sun, 27 Jun 1999 13:58:35 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: About of DNS Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi there! I'm seem that some time ago I heard in this conference that TCPWare DNS server performs periodicaly rescan of updated *.hosts/*.rev files ? I'm is wrong? -- Regards. +.....................pure personal opinion..........................+ HTTP://WWW.RadiusVMS.COM - Frying only on VMS ================================================================================ Archive-Date: Sun, 27 Jun 1999 08:59:23 -0400 Message-ID: <3775F82A.CEF58F40@SMTP.DeltaTel.RU> Date: Sun, 27 Jun 1999 14:08:42 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: NETCU DEBUG /UDP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi there! I'm would like to get some new functionality of NETCU DEBUG /UDP command, for example ability to debug application level protocols. I suspect that can be reached by introducing of external callouts stuff in NETCU's debug. For example if I'm need to debug RADIUS protocol I can type: NETCU DEBUG/UDP /APPLICATION_PROTOCOL=RADIUS ... (of course, that I have wrote XXX$RADIUS.EXE image which perfoms packets parsing and interpretation) I'm is very interested by presence of this feature in a TCPWare TCP and I can help if PSC have not free staff :) -- Regards. +.....................pure personal opinion..........................+ HTTP://WWW.RadiusVMS.COM - Frying only on VMS ================================================================================ Archive-Date: Sun, 27 Jun 1999 11:12:43 -0400 Subject: Re: NETCU DEBUG /UDP Message-ID: <1999Jun27.100854@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 27 Jun 99 10:08:54 -0400 To: Info-TCPware@PROCESS.COM In article <3775F82A.CEF58F40@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > Hi there! > > I'm would like to get some new functionality of NETCU DEBUG /UDP > command, for example ability to debug application level protocols. I > suspect that can be reached by introducing of external callouts stuff in > NETCU's debug. For example if I'm need to debug RADIUS protocol I can > type: > NETCU DEBUG/UDP /APPLICATION_PROTOCOL=RADIUS ... > (of course, that I have wrote XXX$RADIUS.EXE image which perfoms packets > parsing and interpretation) > > I'm is very interested by presence of this feature in a TCPWare TCP and > I can help if PSC have not free staff :) > > -- > Regards. > +.....................pure personal opinion..........................+ > HTTP://WWW.RadiusVMS.COM - Frying only on VMS We have chosen not to add protocol decoding to NETCU DEBUG because TCPDUMP is also being included and it can do that. It may not, however, handle all protocols. Don't think it is "customer extensible" with decoding modules. Note that TCPDUMP can be used to use the same means to get packets as NETCU DEBUG which is sometimes better than placing the Ethernet interface into promiscous mode (as TCPDUMP normally operates). See the "i" command option. - Bernie Volz ================================================================================ Archive-Date: Sun, 27 Jun 1999 11:12:48 -0400 Subject: Re: About of DNS Message-ID: <1999Jun27.100610@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 27 Jun 99 10:06:10 -0400 To: Info-TCPware@PROCESS.COM In article <3775F5CB.15A416E3@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > Hi there! > I'm seem that some time ago I heard in this conference that TCPWare > DNS server performs periodicaly rescan of updated *.hosts/*.rev files ? > I'm is wrong? > > -- > Regards. > +.....................pure personal opinion..........................+ > HTTP://WWW.RadiusVMS.COM - Frying only on VMS You can "signal" the DNS Server to reload these files by issuing the NETCU RELOAD NAMED command. - Bernie Volz ================================================================================ Archive-Date: Sun, 27 Jun 1999 14:14:26 -0400 Message-ID: <3776650B.F828BDB9@SMTP.DeltaTel.RU> Date: Sun, 27 Jun 1999 21:53:15 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: NETCU DEBUG /UDP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hello Bernie! Bernie Volz wrote: > > In article <3775F82A.CEF58F40@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > > Hi there! > > > > I'm would like to get some new functionality of NETCU DEBUG /UDP > > command, for example ability to debug application level protocols. I > > suspect that can be reached by introducing of external callouts stuff in > > NETCU's debug. For example if I'm need to debug RADIUS protocol I can > > type: > > NETCU DEBUG/UDP /APPLICATION_PROTOCOL=RADIUS ... > > (of course, that I have wrote XXX$RADIUS.EXE image which perfoms packets > > parsing and interpretation) > > > > I'm is very interested by presence of this feature in a TCPWare TCP and > > I can help if PSC have not free staff :) > > > > -- > > Regards. > > +.....................pure personal opinion..........................+ > > HTTP://WWW.RadiusVMS.COM - Frying only on VMS > > We have chosen not to add protocol decoding to NETCU DEBUG because TCPDUMP > is also being included and it can do that. It may not, however, handle all > protocols. Don't think it is "customer extensible" with decoding modules. > > Note that TCPDUMP can be used to use the same means to get packets as > NETCU DEBUG which is sometimes better than placing the Ethernet interface > into promiscous mode (as TCPDUMP normally operates). See the "i" command > option. > > - Bernie Volz I have used TCPDUMP... But I'm would like to see debuging output which consist "Atribute = Value" and etc. So, I have another question, have you got any plan to put this functionality (see begin of the mail) in TCPDUMP. My offer with the help still rigth. :) -- Regards. +.....................pure personal opinion..........................+ HTTP://WWW.RadiusVMS.COM - Frying only on VMS ================================================================================ Archive-Date: Mon, 28 Jun 1999 08:11:21 -0400 Sender: schreiber@process.com Date: Mon, 28 Jun 1999 08:08:26 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DA4C5.DD15D0DB.66@process.com> Subject: RE: About of DNS "Ruslan R. Laishev" writes: > > I'm seem that some time ago I heard in this conference that TCPWare >DNS server performs periodicaly rescan of updated *.hosts/*.rev files ? > I'm is wrong? > That is incorrect. Perhaps you are thinking of the DNS Resolver process and the hosts. file? -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 28 Jun 1999 08:42:12 -0400 Message-ID: <377768DA.EC77B8F@SMTP.DeltaTel.RU> Date: Mon, 28 Jun 1999 16:21:46 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: About of DNS Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > > I'm seem that some time ago I heard in this conference that TCPWare > >DNS server performs periodicaly rescan of updated *.hosts/*.rev files ? > > I'm is wrong? > > > > That is incorrect. Perhaps you are thinking of the DNS Resolver process > and the hosts. file? No,no. *.hosts but not hosts. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Mon, 28 Jun 1999 09:07:11 -0400 Message-ID: <377772A3.99494376@PROCESS.COM> Date: Mon, 28 Jun 1999 09:03:31 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: FW: About of DNS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi there! > I'm seem that some time ago I heard in this conference that TCPWare > DNS server performs periodicaly rescan of updated *.hosts/*.rev files ? > I'm is wrong? > TCPware does not read the zone files automatically, you have to restart the DNS server to accomplish this. The TCPWARE:HOSTS. file is checked for updates and reloaded automatically by the TCPware_DNS process and this might be what was referred to in earlier messages. -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Mon, 28 Jun 1999 11:16:29 -0400 Message-ID: <37778040.E9AEEB37@SMTP.DeltaTel.RU> Date: Mon, 28 Jun 1999 18:01:36 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: FW: About of DNS Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Michael Corbett wrote: > > > Hi there! > > I'm seem that some time ago I heard in this conference that TCPWare > > DNS server performs periodicaly rescan of updated *.hosts/*.rev files ? > > I'm is wrong? > > > > TCPware does not read the zone files automatically, you have to > restart the DNS server to accomplish this. The TCPWARE:HOSTS. file is checked > for updates and reloaded automatically by the TCPware_DNS process and this > might be what was referred to in earlier messages. Thanks. > > -- > +-------------------------------------------------------------------------+ > Michael Corbett Email: Corbett@process.com > Process Software Corporation Phone: 800 722-7770 x369 > 959 Concord St. 508 879-6994 x369 > Framingham MA 01701-4682 FAX: 508 879-0042 -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +