Archive-Date: Thu, 1 Jun 2000 13:13:52 -0400 Return-Path: From: Brian Steele (via Deja) Reply-To: Info-TCPware@process.com Subject: TCPWare 5.4 - Remote Username Information Date: Thu, 01 Jun 2000 16:21:01 GMT Message-ID: <8h62h1$4f6$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Hi everyone: The support for some software applications running on our AlphaVMS system is provided by users logging through a remote host, also Alpha VMS. As part of the security procedures, we have a simple DCL script inserted into the logon process that determines the user's remote hostname and username, and rejects the logon if they don't match the access list. Previously, the remote users logged in using the DECNet CTERM protocol,and the remote nodename/username could be extracted from the process by using the following DCL script: $ Access_Info = F$GETJPI("","TT_ACCPORNAM") $! IF f$EXTRACT(0,3,ACCESS_INFO) .EQS. "LAT" THEN GOTO FINISH $ Time = F$TIME() $ Remote_Node = F$ELEMENT(0,":",Access_Info) $ Remote_User = F$ELEMENT(2,":",Access_Info) $! An example of a value for "Access_Info" is "SERVER::USERNAME". The script above returns the following values: Remote_Node = SERVER Remote_User = USERNAME Due to our corporate policy regarding IP, we are now moving to using IP between our systems instead of DECnet. The replacement for the CTERM protocol has been identified as TELNET. Unfortunately, it seems that TELNET, at least TCPWare's implementation of TELNET, does NOT return the name of the remote user account - F$GETJPI("","TT_ACCPORNAM") returns the name of the remote host only. This of course causes our security procedure to fail. Any ideas on how to get around this? Regards, Brian Steele Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Fri, 2 Jun 2000 00:07:41 -0400 Return-Path: From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: TCPWare 5.4 - Remote Username Information Message-ID: <3936bb72.524144494f47414741@radiogaga.harz.de> Date: Thu, 01 Jun 2000 21:37:22 +0200 Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Brian Steele (via Deja) (steele_b@spiceisle.com) wrote: : Previously, the remote users logged in using the DECNet CTERM protocol, : and the remote nodename/username could be extracted from the process ... : Due to our corporate policy regarding IP, we are now moving to using IP : between our systems instead of DECnet. The replacement for the CTERM : protocol has been identified as TELNET. Unfortunately, it seems that : TELNET, at least TCPWare's implementation of TELNET, does NOT return the : name of the remote user account - F$GETJPI("","TT_ACCPORNAM") returns : the name of the remote host only. This of course causes our security : procedure to fail. : : Any ideas on how to get around this? TCP/IP - regardless of the implementations - doesn't provide that information. cu, Martin -- | Martin Vorlaender | VMS & WNT programmer OpenVMS: When you | work: mv@pdv-systeme.de KNOW where you want | http://www.pdv-systeme.de/users/martinv/ to go today. | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Sun, 4 Jun 2000 11:22:16 -0400 Return-Path: From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: BINDIG an UDP socket (DEC TCPIP & PSC MULTINET/TCPWARE) Message-ID: Date: Sun, 4 Jun 2000 19:15:14 +0400 To: Info-TCPware@PROCESS.COM Hi All! Some additions, I just run test program under UCX 4.2/VAX - is no problem here, it means that DEC TCPIP 5.0 is not compatible with DEC UCX 4.x. Just for information for other developers. Ruslan R. Laishev wrote in message <3935415B.DFC2B61E@SMTP.DeltaTel.RU>... >Hi There! > > I have an application which binding several DGRAM-sockets to different secondary IP >addreses. I found a difference in behaviour when binding a socket: > 1) I bind 0.0.0.0:1645 socket - Ok. > 2) I bind 172.16.0.45:1645 socket - PSC MULTINET/TCPWARE - Ok. > DEC TCPIP - SS$_DUPLNAM. > > What is solution? What the misbehaving is right? > > Checked under/with: > > TCPWare TCP - 5.3-3,5.4-3, Multinet,4.x - VMS/Alpha 7.1-1h1,7.2-1 > DEC TCPIP 5.0a (w/o ECOs) - VMS/Alpha 7.2-1. > -- + C U, SysMan at DLS ...................................................+ http://www.radiusvms.com | Cel: +7 (901) 971-3222 http://www.levitte.org/~rlaishev | Fax: +7 (812) 115-1035 + Flying by Su-27........................................ Frying on VMS + ================================================================================ Archive-Date: Sun, 4 Jun 2000 15:13:03 -0400 Date: Sun, 4 Jun 2000 15:16:00 -0400 From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com To: INFO-TCPWARE@PROCESS.COM Message-ID: <000604151600.cc5f1@ENDOR.COM> Subject: POP error accept failed Has anyone seen this error, I got about 10K lines of this, repeating. I had to kill the pop3 server. 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed 2000-06-04 14:18:43 accept failed TCPWARE $ R TCPWARE:NETCU NETCU> SHO VER TCPware(R) for OpenVMS V5.4-2 Copyright (c) 1999 Process Software Corporation VMS version 7.2-1 Image Identification Information image name: "POP3D" image file identification: "TCPWARE V5.4-2 " image file build identification: "" link date/time: 20-SEP-1999 03:04:55.38 linker identification: "A11-50" john babiarz ================================================================================ Archive-Date: Mon, 5 Jun 2000 11:24:46 -0400 Message-ID: <4.2.0.58.20000605092340.00b49d80@pop.clsp.uswest.net> Date: Mon, 05 Jun 2000 09:25:22 -0600 To: Info-TCPware@process.com From: Dan O'Reilly Reply-To: Info-TCPware@process.com Subject: Re: POP error accept failed In-Reply-To: <000604151600.cc5f1@ENDOR.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The pop3 server attempted to accept a connection request from a client, but was unable to. Unfortunately, the reason for the failure isn't logged anywhere. After you stopped the pop3 server, did you restart it successfully? Had this system been up for a long time? Was there some other event on your network that could be related to this? At 01:16 PM 6/4/00 , babiarz@ENDOR.COM wrote: >Has anyone seen this error, I got about 10K lines of this, repeating. I >had to kill the pop3 server. > > >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed >2000-06-04 14:18:43 accept failed > > > >TCPWARE $ R TCPWARE:NETCU >NETCU> SHO VER >TCPware(R) for OpenVMS V5.4-2 Copyright (c) 1999 Process Software Corporation > > >VMS version 7.2-1 > Image Identification Information > > image name: "POP3D" > image file identification: "TCPWARE V5.4-2 " > image file build identification: "" > link date/time: 20-SEP-1999 03:04:55.38 > linker identification: "A11-50" > > > >john babiarz ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Time flies like an arrow. Fruit | | Process Software Corporation | flies like a banana." | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ ================================================================================ Archive-Date: Mon, 5 Jun 2000 15:46:13 -0400 Return-Path: Message-ID: <393C0041.D80AA84E@SMTP.DeltaTel.RU> Date: Mon, 05 Jun 2000 23:32:17 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: POP error accept failed Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi John! It cab be a result of DoS attack to your POP3 server, did you check incomming network traffic by TCPDUMP or by NETCU DEBUG /TCP ? babiarz@ENDOR.COM wrote: > > Has anyone seen this error, I got about 10K lines of this, repeating. I > had to kill the pop3 server. > > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > 2000-06-04 14:18:43 accept failed > > TCPWARE $ R TCPWARE:NETCU > NETCU> SHO VER > TCPware(R) for OpenVMS V5.4-2 Copyright (c) 1999 Process Software Corporation > > VMS version 7.2-1 > Image Identification Information > > image name: "POP3D" > image file identification: "TCPWARE V5.4-2 " > image file build identification: "" > link date/time: 20-SEP-1999 03:04:55.38 > linker identification: "A11-50" > > john babiarz -- +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Tue, 6 Jun 2000 10:54:58 -0400 Sender: schreiber@process.com Date: Tue, 6 Jun 2000 10:53:51 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB32D.F6F6F03B.145@process.com> Subject: RE: POP error accept failed babiarz@ENDOR.COM writes: >NETCU> SHO VER >TCPware(R) for OpenVMS V5.4-2 Copyright (c) 1999 Process Software Corporation You're still running the 5.4 Beta version? You should probably upgrade to 5.4-3 unless you have a specific reason? -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 6 Jun 2000 21:50:42 -0400 Return-Path: Subject: Re: MX problems since TCPware V5.4-3 From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <393da8e3@news.kapsch.co.at> Date: 7 Jun 2000 03:44:03 +0200 To: Info-TCPware@PROCESS.COM In article <000530194728.202000c0@goatley.com>, Hunter Goatley writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >>Ok, if PATH_MTU is the problem (which I'll check), was it introduced with >>V5.4-3 ? >> >No, it's been around a while. But a broken router was added between >you and .CH around the same time you upgraded. > >It's a guess, but it matches what you're seeing.... And you won a cigar ;-) /NOPATH did it. btw: Don't do a STOP/TCP (with an START/TCP/NOPATH thereafter). Sad things may happen until reboot (like VPM Server looping at prio 15)... btw: What is the supported way of adding such qualifiers to TCPware startup ? It seems, editing STARTNET.COM is the only and unsupported way to go ? Ok, I better ask this again in the correct discussion group... Now, we'll see what the ISP says... -- 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, 7 Jun 2000 08:55:57 -0400 Return-Path: From: Adrian.Parker@rb.cwplc.com Reply-To: Info-TCPware@process.com Subject: COPY /FTP possible? Date: Wed, 07 Jun 2000 12:44:39 GMT Message-ID: <8hlg3j$s40$1@nnrp1.deja.com> To: Info-TCPware@process.com We are running TCPware v5.3-3 Is is possible to make TCPware work with the VMS integrated commands such as 'copy /ftp' and 'copy /rcp', or do these only work with Compaq TCP/IP services? When I try, I get the following error; $ copy/ftp something anything %TCPWARE_FTP-W-CONFLICT, illegal combination of command elements - check documen tation Thanks and regards, Adrian Parker Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Wed, 7 Jun 2000 09:04:52 -0400 Reply-To: Info-TCPware@process.com From: "Joe Gray" To: Subject: RE: COPY /FTP possible? Date: Wed, 7 Jun 2000 08:03:56 -0500 Message-ID: <000501bfd080$d71a9ca0$f13f366a@jgpc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <8hlg3j$s40$1@nnrp1.deja.com> See if you have "copy" defined to be more than just "copy. Try doing "show symbol copy*" to see if an invalid combination of switches is present. If so, fix by by doing "copy:=copy" before the "copy/ftp". -----Original Message----- From: Adrian.Parker@rb.cwplc.com [mailto:Adrian.Parker@rb.cwplc.com] Sent: Wednesday, June 07, 2000 7:45 AM To: Info-TCPware@process.com Subject: COPY /FTP possible? We are running TCPware v5.3-3 Is is possible to make TCPware work with the VMS integrated commands such as 'copy /ftp' and 'copy /rcp', or do these only work with Compaq TCP/IP services? When I try, I get the following error; $ copy/ftp something anything %TCPWARE_FTP-W-CONFLICT, illegal combination of command elements - check documen tation Thanks and regards, Adrian Parker Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Wed, 7 Jun 2000 09:16:06 -0400 Message-ID: <393E4AC1.1FF72F91@PROCESS.COM> Date: Wed, 07 Jun 2000 09:14:41 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: COPY /FTP possible? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > We are running TCPware v5.3-3 > > Is is possible to make TCPware work with the VMS integrated commands > such as 'copy /ftp' and 'copy /rcp', or do these only work with Compaq > TCP/IP services? > > When I try, I get the following error; > > $ copy/ftp something anything > %TCPWARE_FTP-W-CONFLICT, illegal combination of command elements - > check documen > tation The following works for me - $ copy/ftp login.com alcor.process.com"corbett xxxxxxxx"::t.t You might have a symbol set up for copy that uses a qualifier that is not valid with the /FTP. Do a SHOW SYM COPY to see. Also make sure you have the following logicals defined - "OPENVMS$FTP" = "TCPWARE:FTP.EXE" "OPENVMS$FTPDIR" = "TCPWARE:FTP.EXE" regards Mike -- +-------------------------------------------------------------------------+ 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: Wed, 7 Jun 2000 10:25:39 -0400 Sender: schreiber@process.com Date: Wed, 7 Jun 2000 10:24:45 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB3F3.10A48D16.57@process.com> Subject: RE: COPY /FTP possible? Adrian.Parker@rb.cwplc.com writes: > >Is is possible to make TCPware work with the VMS integrated commands >such as 'copy /ftp' and 'copy /rcp', or do these only work with Compaq >TCP/IP services? > Nope... all three products have it. > >$ copy/ftp something anything >%TCPWARE_FTP-W-CONFLICT, illegal combination of command elements - >check documentation > What you have for 'something' and 'anything' is key here. Are you sure you have a node specified? (System)-> copy/ftp login.com test.com %TCPWARE_FTP-W-CONFLICT, illegal combination of command elements - check documentation (System)-> copy/ftp login.com theta::test.com %TCPWARE_FTP-E-LOGINFAIL, failed login attempt as username anonymous -TCPWARE-I-REPLY, server's reply was "530 ftp disallowed." (System)-> copy/ftp login.com theta"user password"::test.com (System)-> I'm guessing you don't have the syntax correct on your from and to filenames in the specification of where and who, and you should... "check documentation" :) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 7 Jun 2000 11:58:17 -0400 Sender: bryant@process.com Date: Wed, 7 Jun 2000 11:57:22 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009EB400.00D79CC2.27@process.com> Subject: Re: MX problems since TCPware V5.4-3 eplan@kapsch.net (Peter LANGSTOEGER) writes: > >In article <000530194728.202000c0@goatley.com>, Hunter Goatley writes: >>eplan@kapsch.net (Peter LANGSTOEGER) writes: >>>Ok, if PATH_MTU is the problem (which I'll check), was it introduced with >>>V5.4-3 ? >>> >>No, it's been around a while. But a broken router was added between >>you and .CH around the same time you upgraded. Yes, it has been around for several years. Note it could either be a broken router that doesn't send the ICMP messages regarding dropping packets for having DON"T FRAGMENT set on a packet that needs fragmenting to be forward, or it could be that a firewall somewhere is blocking ICMP messages - a bad idea. >>It's a guess, but it matches what you're seeing.... > >And you won a cigar ;-) /NOPATH did it. > >btw: Don't do a STOP/TCP (with an START/TCP/NOPATH thereafter). Sad things >may happen until reboot (like VPM Server looping at prio 15)... You don't need to STOP/TCP. Here is some help for NETCU START/TCP" NOTE: If you have already started TCP, you can issue this command to change a parameter value. However, if you do not explicitly specify a parameter, it reverts to its default value as described below. So, be sure to keep any other qualifiers as well. >btw: What is the supported way of adding such qualifiers to TCPware startup ? >It seems, editing STARTNET.COM is the only and unsupported way to go ? >Ok, I better ask this again in the correct discussion group... The most common thing is to add it in TCPWARE:ROUTING.COM. >Now, we'll see what the ISP says... See if it is the ISP or a firewall... >-- >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 ------------------------------------------------------------- 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, 7 Jun 2000 12:22:34 -0400 Return-Path: Subject: Re: MX problems since TCPware V5.4-3 From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <393e7602$1@news.kapsch.co.at> Date: 7 Jun 2000 18:19:14 +0200 To: Info-TCPware@PROCESS.COM In article <009EB400.00D79CC2.27@process.com>, Geoff Bryant writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >>In article <000530194728.202000c0@goatley.com>, Hunter Goatley writes: >>>eplan@kapsch.net (Peter LANGSTOEGER) writes: >>>>Ok, if PATH_MTU is the problem (which I'll check), was it introduced with >>>>V5.4-3 ? >>>> >>>No, it's been around a while. But a broken router was added between >>>you and .CH around the same time you upgraded. > >Yes, it has been around for several years. Note it could either be a broken >router that doesn't send the ICMP messages regarding dropping packets for >having DON"T FRAGMENT set on a packet that needs fragmenting to be forward, or >it could be that a firewall somewhere is blocking ICMP messages - a bad idea. So, what do you suggest ? Enabling ICMP passing through the FW or continue using /NOPATH_MTU ? >>btw: Don't do a STOP/TCP (with an START/TCP/NOPATH thereafter). Sad things >>may happen until reboot (like VPM Server looping at prio 15)... > >You don't need to STOP/TCP. Here is some help for NETCU START/TCP" > > NOTE: If you have already started TCP, you can issue this command to > change a parameter value. However, if you do not explicitly specify a > parameter, it reverts to its default value as described below. > >So, be sure to keep any other qualifiers as well. Thanks. That was news to me. Sounds good. But now, how to check which qualifiers are currently in use ? There is no NETCU SHOW TCP. What did I miss ? >>btw: What is the supported way of adding such qualifiers to TCPware startup ? >>It seems, editing STARTNET.COM is the only and unsupported way to go ? > >The most common thing is to add it in TCPWARE:ROUTING.COM. Ok. If it can be set after the first NETCU START/TCP command, then this sounds logical. But I wasn't aware of this fact. >>Now, we'll see what the ISP says... > >See if it is the ISP or a firewall... It is the firewall, but this packages are blocked since day 1 (remember Ping-of-Death and later SMURF ?). The ISP did change something the last weeks (enabled an IP over IP tunnel with 1500 Byte MTU max) and so this FW config problem popped up. Thanks all for listening/reading/guessing/suggesting. -- 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, 7 Jun 2000 15:50:58 -0400 Sender: bryant@process.com Date: Wed, 7 Jun 2000 15:50:03 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009EB420.81E61670.165@process.com> Subject: Re: MX problems since TCPware V5.4-3 eplan@kapsch.net (Peter LANGSTOEGER) writes: > >In article <009EB400.00D79CC2.27@process.com>, Geoff Bryant writes: >>eplan@kapsch.net (Peter LANGSTOEGER) writes: >>>In article <000530194728.202000c0@goatley.com>, Hunter Goatley writes: >>>>eplan@kapsch.net (Peter LANGSTOEGER) writes: >>>>>Ok, if PATH_MTU is the problem (which I'll check), was it introduced with >>>>>V5.4-3 ? >>>>> >>>>No, it's been around a while. But a broken router was added between >>>>you and .CH around the same time you upgraded. >> >>Yes, it has been around for several years. Note it could either be a broken >>router that doesn't send the ICMP messages regarding dropping packets for >>having DON"T FRAGMENT set on a packet that needs fragmenting to be forward, or >>it could be that a firewall somewhere is blocking ICMP messages - a bad idea. > >So, what do you suggest ? >Enabling ICMP passing through the FW or continue using /NOPATH_MTU ? Well from the rest of your message, /NOPATH_MTU may be your only choice. >>>btw: Don't do a STOP/TCP (with an START/TCP/NOPATH thereafter). Sad things >>>may happen until reboot (like VPM Server looping at prio 15)... >> >>You don't need to STOP/TCP. Here is some help for NETCU START/TCP" >> >> NOTE: If you have already started TCP, you can issue this command to >> change a parameter value. However, if you do not explicitly specify a >> parameter, it reverts to its default value as described below. >> >>So, be sure to keep any other qualifiers as well. > >Thanks. That was news to me. Sounds good. >But now, how to check which qualifiers are currently in use ? >There is no NETCU SHOW TCP. What did I miss ? Um, well, if you know the internal data structures you can check in SDA, but that doesn't help you. I don't know of a SHOW command - sounds like a good enhancement. I would do a quick search of TCPWARE:*.COM for START/TCP to find any that are needed. >>>btw: What is the supported way of adding such qualifiers to TCPware startup ? >>>It seems, editing STARTNET.COM is the only and unsupported way to go ? >> >>The most common thing is to add it in TCPWARE:ROUTING.COM. > >Ok. If it can be set after the first NETCU START/TCP command, then this >sounds logical. But I wasn't aware of this fact. Well, you can edit STARTNET.COM and get it there, but any TCPWARE upgrade could get you on that. That's why ROUTING.COM is a "better, more correct" place. >>>Now, we'll see what the ISP says... >> >>See if it is the ISP or a firewall... > >It is the firewall, but this packages are blocked since day 1 (remember >Ping-of-Death and later SMURF ?). The ISP did change something the last >weeks (enabled an IP over IP tunnel with 1500 Byte MTU max) and so this >FW config problem popped up. Well, it's your call. Maybe you can allow ICMP DEST UNREACHABLEs through and block pings as a compromise. >Thanks all for listening/reading/guessing/suggesting. >-- >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 ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 8 Jun 2000 06:12:50 -0400 Return-Path: From: adrian_parker@my-deja.com Reply-To: Info-TCPware@process.com Subject: Compaq FTSO -> TCPware FTP server issue Date: Thu, 08 Jun 2000 09:55:16 GMT Message-ID: <8hnqi0$k7g$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM We use Compaq FTSO 1.5.1 client on VAX/VMS V7.1 which is a front-end scheduler/pre & post processor FTP client. This used to work fine copying to a TCPware 5.3-3 server but since our customer has upgraded to TCPware 5.4-3 we are seeing some strange errors. I've attached some output and all the log files I could find to try to demonstrate the problem. Any help would be great.. $ dir ftso_test.txt Directory TECH:[TOOLS] FTSO_TEST.TXT;1 Total of 1 file. $ ftso set default debug=on $ ftso copy ftso_test.txt SYSTEMX/RELEASE/**password**::*.* %FTSO-I-JOBID, FTSO Job-id is 905, Job 905 started $ TECH:[TOOLS]FTSO_TEST.TXT; not copied to ftso_test.txt $ %FTSO-E-JOBFAIL, job 0905 failed $ ftso set default debug=off $ type sys$login:ftso_0905.log FTSO Job: 0905 (F) Posted at: Thu Jun 1 12:12:52 2000 By: PARKER_A Command: copy ftso_test.txt SYSTEMX/RELEASE/************::*.* Completed at: Thu Jun 1 12:13:04 2000 Status: error Terminated at: Thu Jun 1 12:13:03 2000 Status: error %cftp_set_idle_time, normal 500 Unknown argument "IDLE" to SITE command. %%cftso_put_file, FTP__REMERROR - 550 %RMS-E-FNF, file not found 214 SITE NONE recognized. %FTSO-E-TASKFAIL, secondary job 090501 has failed $ type ftso$disk:[ftso]ftso_debug_0905.log Thu Jun 1 12:12:54 2000 <0905> INFO FTSO_CLTP_MAIN\main - started Thu Jun 1 12:12:54 2000 <0905> INFO FTSO_CLTP_SCHEDULER\ftso_submit_tasks - secondary task submitted Thu Jun 1 12:12:54 2000 <0905> INFO FTSO_CLTP_MAIN\main - successfully submitted tasks Thu Jun 1 12:12:55 2000 <090501> INFO FTSO_CLTS_MAIN\ftso_initialize - started Thu Jun 1 12:12:55 2000 <090501> INFO -- privilege current mask : ffffffff ffffffff Thu Jun 1 12:12:55 2000 <090501> INFO -- privilege mask input : ffffffff ffffffff Thu Jun 1 12:12:55 2000 <090501> INFO -- privilege mask set to : ffffffff ffffffff Thu Jun 1 12:12:55 2000 <090501> INFO FTSO_CLTS_SCHEDULER\ftso_remote_copy - remote file copy started Thu Jun 1 12:12:55 2000 <090501> INFO FTSO_CLTS_PROTOCOL_1.5 \ftso2_copy_protocol - file copy in normal mode Thu Jun 1 12:12:56 2000 <090501> INFO connecting SYSTEMX on port 21 Thu Jun 1 12:12:56 2000 <090501> INFO <-220 SYSTEMX FTP-OpenVMS FTPD V5.4-3 (c) 1999 Process Software Corpo ration Thu Jun 1 12:12:56 2000 <090501> DEBUG cftp_set_fmod RFM= RAT= Thu Jun 1 12:12:56 2000 <090501> INFO Remote Login as user RELEASE Thu Jun 1 12:12:56 2000 <090501> INFO ->USER Thu Jun 1 12:12:57 2000 <090501> INFO <-331 Password required. Thu Jun 1 12:12:57 2000 <090501> INFO ->PASS Thu Jun 1 12:12:57 2000 <090501> INFO <-230 User logged in, proceed. Thu Jun 1 12:12:57 2000 <090501> INFO ->TYPE A Thu Jun 1 12:12:58 2000 <090501> INFO <-200 TYPE command okay. Thu Jun 1 12:12:58 2000 <090501> INFO ->SYST Thu Jun 1 12:12:58 2000 <090501> INFO <-215 VMS TCPware V5.4-3 Thu Jun 1 12:12:58 2000 <090501> INFO VMS operating system detected Thu Jun 1 12:12:58 2000 <090501> INFO ->SITE IDLE 600 Thu Jun 1 12:12:59 2000 <090501> INFO <-500 Unknown argument "IDLE" to SITE command. Thu Jun 1 12:12:59 2000 <090501> INFO FTSO_CLTS_PROTOCOL_1.5 \ftso2_copy_protocol - logged in successfully Thu Jun 1 12:12:59 2000 <090501> INFO ->HELP Thu Jun 1 12:12:59 2000 <090501> INFO <-214-The following commands are allowed: Thu Jun 1 12:12:59 2000 <090501> INFO <-214- ABOR, ACCT, ALLO, APPE, CDUP, Thu Jun 1 12:12:59 2000 <090501> INFO <-214- CWD, DELE, HELP, LIST, MKD, MODE, Thu Jun 1 12:12:59 2000 <090501> INFO <-214- NLST, NOOP, PASS, PASV, PORT, Thu Jun 1 12:12:59 2000 <090501> INFO <-214- PWD, QUIT, REIN, RETR, RNFR, RNTO, Thu Jun 1 12:13:00 2000 <090501> INFO <-214- RMD, SITE, STAT, STOR, STOU, STRU, Thu Jun 1 12:13:00 2000 <090501> INFO <-214- SYST, TYPE, USER, XCUP, XCWD, Thu Jun 1 12:13:00 2000 <090501> INFO <-214 XMKD, XPWD and XRMD. Thu Jun 1 12:13:00 2000 <090501> INFO ->PORT 146,135,182,4,14,218 Thu Jun 1 12:13:00 2000 <090501> INFO <-200 PORT command okay. Thu Jun 1 12:13:00 2000 <090501> INFO ->NLST ftso_test.txt Thu Jun 1 12:13:00 2000 <090501> INFO <-150 Opening data connection for ftso_test.txt. Thu Jun 1 12:13:01 2000 <090501> INFO <-552 RMS-E-FNF, file not found, ftso_test.txt Thu Jun 1 12:13:01 2000 <090501> INFO ->SITE +VMS+ Thu Jun 1 12:13:01 2000 <090501> INFO <-214 SITE +VMS+ recognized. Thu Jun 1 12:13:01 2000 <090501> INFO UCX mode enabled: 3 Thu Jun 1 12:13:01 2000 <090501> INFO ->PORT 146,135,182,4,14,219 Thu Jun 1 12:13:01 2000 <090501> INFO <-200 PORT command okay. Thu Jun 1 12:13:01 2000 <090501> INFO ->STOR ftso_test.txt Thu Jun 1 12:13:02 2000 <090501> INFO <-150 Opening data connection for SYSTEMX_DISK_2:[RELEASE]FTSO_TEST.TXT;1. Thu Jun 1 12:13:02 2000 <090501> DEBUG Disk size =8192 Thu Jun 1 12:13:02 2000 <090501> DEBUG Net size =8192 Thu Jun 1 12:13:02 2000 <090501> DEBUG Section size =49152 Thu Jun 1 12:13:02 2000 <090501> DEBUG Opening TECH:[TOOLS] FTSO_TEST.TXT; in BINARY mode Thu Jun 1 12:13:02 2000 <090501> DEBUG put_fdl_data Thu Jun 1 12:13:02 2000 <090501> DEBUG Transfer starting at File Position: 0 Thu Jun 1 12:13:02 2000 <090501> DEBUG Transferring file Thu Jun 1 12:13:02 2000 <090501> DEBUG 72 bytes read Thu Jun 1 12:13:02 2000 <090501> DEBUG 72 bytes sent Thu Jun 1 12:13:03 2000 <090501> INFO <-550 %RMS-E-FNF, file not found Thu Jun 1 12:13:03 2000 <090501> INFO ->SITE NONE Thu Jun 1 12:13:03 2000 <090501> INFO <-214 SITE NONE recognized. Thu Jun 1 12:13:03 2000 <090501> INFO FTSO_CLTS_SCHEDULER\ftso2_transfer_protocol - check recovery with status = 268338832 Thu Jun 1 12:13:03 2000 <090501> INFO FTSO_CLTS_PROTOCOL_1.5 \ftso2_abort_transfer - started Thu Jun 1 12:13:03 2000 <090501> INFO ->QUIT Thu Jun 1 12:13:03 2000 <090501> INFO <-221 Service closing connection. Thu Jun 1 12:13:03 2000 <090501> INFO FTSO_CLTS_PROTOCOL_1.5 \ftso2_abort_transfer - finished Thu Jun 1 12:13:03 2000 <090501> INFO FTSO_CLTS_MAIN\ftso_error_exit - error exit started Thu Jun 1 12:13:03 2000 <090501> INFO FTSO_CLTS_SCHEDULER\ftso_job_completion - job completion started Thu Jun 1 12:13:03 2000 <090501> ERROR %FTSO-E-TASKFAIL, secondary job 090501 has failed Thu Jun 1 12:13:03 2000 <090501> INFO FTSO_CLTS_SCHEDULER\ftso_job_completion - job completion finished Thu Jun 1 12:13:04 2000 <0905> INFO FTSO_CLTP_SCHEDULER\ftso_job_completion - job completion started Thu Jun 1 12:13:04 2000 <0905> ERROR %FTSO-E-COPFAIL, transfer failure Thu Jun 1 12:13:04 2000 <0905> INFO FTSO_CLTP_SCHEDULER\ftso_job_completion - job completion finished Thu Jun 1 12:13:04 2000 <0905> INFO FTSO-E-COPFAIL, transfer failure Log file from TCPware FTP server node SYSTEMX: -------------------------------------------------------- FTP Login request received at Thu Jun 1 07:09:13 2000 from remote IP address 146.135.182.4 (lona02) -------------------------------------------------------- >>> 230 User logged in, proceed. <<< TYPE A >>> 200 TYPE command okay. <<< SYST Banner not translated >>> 215 VMS TCPware V5.4-3 <<< SITE IDLE 600 >>> 500 Unknown argument "IDLE" to SITE command. <<< HELP >>> 214-The following commands are allowed: >>> 214- ABOR, ACCT, ALLO, APPE, CDUP, >>> 214- CWD, DELE, HELP, LIST, MKD, MODE, >>> 214- NLST, NOOP, PASS, PASV, PORT, >>> 214- PWD, QUIT, REIN, RETR, RNFR, RNTO, >>> 214- RMD, SITE, STAT, STOR, STOU, STRU, >>> 214- SYST, TYPE, USER, XCUP, XCWD, >>> 214 XMKD, XPWD and XRMD. <<< PORT 146,135,182,4,14,218 >>> 200 PORT command okay. <<< NLST ftso_test.txt >>> 150 Opening data connection for ftso_test.txt. >>> 552 RMS-E-FNF, file not found, ftso_test.txt <<< SITE +VMS+ >>> 214 SITE +VMS+ recognized. <<< PORT 146,135,182,4,14,219 >>> 200 PORT command okay. <<< STOR ftso_test.txt >>> 150 Opening data connection for SYSTEMX_DISK_2:[RELEASE] FTSO_TEST.TXT;1. %FDL-E-SYNTAX, syntax error in statement 21 \ \ >>> 550 %RMS-E-FNF, file not found <<< SITE NONE >>> 214 SITE NONE recognized. <<< QUIT >>> 221 Service closing connection. RELEASE job terminated at 1-JUN-2000 07:09:19.37 Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Thu, 8 Jun 2000 06:56:48 -0400 Return-Path: Subject: Re: Compaq FTSO -> TCPware FTP server issue From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <393f7b59$1@news.kapsch.co.at> Date: 8 Jun 2000 12:54:17 +0200 To: Info-TCPware@PROCESS.COM In article <8hnqi0$k7g$1@nnrp1.deja.com>, adrian_parker@my-deja.com writes: >We use Compaq FTSO 1.5.1 client on VAX/VMS V7.1 which is a front-end >scheduler/pre & post processor FTP client. > >This used to work fine copying to a TCPware 5.3-3 server but since our >customer has upgraded to TCPware 5.4-3 we are seeing some strange >errors. Without going into details, the TCPware FTP server has changed with V5.4-3 and there are now a lot of related patches since the initial release of V5.4-3. Check for the FTP_V543P070 (maybe also the DRIVERS_V543P022) patch and see in the release notes, if your problem is mentioned there. -- 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: Thu, 8 Jun 2000 09:57:40 -0400 Sender: goatley@triton.process.com Return-Path: Return-Path: From: adrian_parker@my-deja.com Reply-To: Info-TCPware@process.com Subject: RE: COPY /FTP possible? Date: Thu, 08 Jun 2000 09:34:27 GMT Message-ID: <8hnpb3$jbr$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Thanks all, it works if I use valid filenames! You have to admit the error message is a bit misleading tho :-) Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Fri, 9 Jun 2000 10:07:34 -0400 Return-Path: From: Andy Williams Reply-To: Info-TCPware@process.com Subject: DE600 board in ES40 Date: Fri, 9 Jun 2000 12:16:08 +0100 Message-ID: <78E5B8E274DBD1118D6800805FE60E772CD697@ntprdex4.admin.liffe.com> To: Info-TCPware@PROCESS.COM We've just taken delivery of an ES40 with a DE600 network card. Unfortunately, TCPware seems to barf on installation because it doesn't recognise the line type of EIA-0. Is there a patch available for this or has anybody managed to successfully configure this ? -Andy ================================================================================ Archive-Date: Fri, 9 Jun 2000 10:25:27 -0400 Return-Path: Message-ID: <3940F9CF.C4F15C1F@SMTP.DeltaTel.RU> Date: Fri, 09 Jun 2000 18:06:07 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: SO_RCVTIMEO Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! Need some consulting, I try to set receive timeout option see ckeleton follows: { ... struct timeval tmo = {1,1}; socket (...); bind (...) if ( 0 > setsockopt (ctx.sockfd,SOL_SOCKET,SO_RCVTIMEO,&tmo,sizeof(tmo)) ) perror("setsockopt"); } setsockopt: non-translatable vms error code: 0x34C %rms-f-dev, error in device name or inappropriate device type for operation What is wrong ? -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom Inc, 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: Fri, 9 Jun 2000 10:36:09 -0400 Message-ID: <39410246.F07425C9@onsight.nl> Date: Fri, 09 Jun 2000 16:42:14 +0200 From: "Marcel Knippen" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: DE600 board in ES40 References: <78E5B8E274DBD1118D6800805FE60E772CD697@ntprdex4.admin.liffe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy, Please try : $ define/sys/exec ewa0 eia0 And then configure EWA-0 should work. (or if ewa0 is already in use, $ define/sys/exec ewb0 eia0 and configure EWA-1) If this is a DE602 card, with 2 NICs, make sure to configure both interfaces. In our case, configuring only one NIC did not work untill we configures both. Now everything is working fine. As far as I know, Process will add support of eia devices in the next version. Currently there is no patch available. Regards, Marcel Andy Williams wrote: > > We've just taken delivery of an ES40 with a DE600 network card. > Unfortunately, TCPware seems to barf on installation because it doesn't > recognise the line type of EIA-0. > > Is there a patch available for this or has anybody managed to > successfully configure this ? > > -Andy -- Marcel Knippen -- Onsight Solutions BV Postbus 5332 Simon Stevinweg 27 6802 EH ARNHEM 6827 BS ARNHEM Tel. (+31) 26 3684870 Fax. (+31) 26 3684871 http://www.onsight.nl ================================================================================ Archive-Date: Fri, 9 Jun 2000 10:43:42 -0400 Message-ID: <39410251.59537FAB@PROCESS.COM> Date: Fri, 09 Jun 2000 10:42:25 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: DE600 board in ES40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > We've just taken delivery of an ES40 with a DE600 network card. > Unfortunately, TCPware seems to barf on installation because it doesn't > recognise the line type of EIA-0. > > Is there a patch available for this or has anybody managed to > successfully configure this ? > > -Andy > Andy, You can, through the use of logicals, trick TCPware into recognizing the EIA0 device. 1.) First is to define a logical for a device type that TCPware recognizes that points to the new device. I suggest using EWH0 since the system probably wont have eight interfaces so this won't conflict with anything. $ DEFINE/SYSTEM/EXEC EWH0 EIA0 2.) Execute TCPWARE:CNFNET TCP to configure the base TCP configuration. You will be prompted Enter the line identifications The TCPware EWA-x lines identifications are used for the EWxx devices. EWA-0 would be used for device EWA-0, EWA-2 for EWB0, EWA-3 for EWC0, and we will use EWA-7 for EWH0. You will want to enter the loopback device (LPB-0), EWA-7 (for the EWH0 logical that references EIA0), and any other devices you need to configure. You will then proceed with the configuration as normal and enter the proper IP addresses and other information for each line you configured. regards Michael -- +-------------------------------------------------------------------------+ 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: Fri, 9 Jun 2000 11:19:21 -0400 Sender: schreiber@process.com Date: Fri, 9 Jun 2000 11:18:21 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB58C.E216912A.151@process.com> Subject: RE: SO_RCVTIMEO "Ruslan R. Laishev" writes: > >struct timeval tmo = {1,1}; > >if ( 0 > setsockopt (ctx.sockfd,SOL_SOCKET,SO_RCVTIMEO,&tmo,sizeof(tmo)) ) >perror("setsockopt"); >} > >setsockopt: non-translatable vms error code: 0x34C [...] > > What is wrong ? > $ exit %x34c %SYSTEM-F-IVBUFLEN, invalid buffer length Table A-5 in the setsockopt documentation in the TCPware programmers guide: SO_RCVTIMEO Sets the timeout value for datagram (UDP) sockets when the MSG_TIME flag is used in socket_recv or recvfrom calls. The optval option is the address of a short containing the timeout time (in seconds); optlen = sizeof (short). The default value (set by socket) is 5 seconds. ------------ struct timeval is 2 longs, so the size of struct timeval is 4 times the size it should be. You should be passing in a short, the number of seconds you want to set it to be. So if you want it to be 1 second, you'd want to have: u_short tmo; tmo = 1; -Jeff ================================================================================ Archive-Date: Fri, 9 Jun 2000 15:33:18 -0400 Return-Path: Message-ID: <39414550.B46A7D89@SMTP.DeltaTel.RU> Date: Fri, 09 Jun 2000 23:28:16 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: SO_RCVTIMEO Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi Jeff! I'm basing on UCX docs , and I have readed *nix docs for setsockopt, I see that PSC implementation is not compatible with "traditional" (*nix) socket interface -------------------------------- CC/list/preff=all/nowarn/include=([],ORA_RDBMS,ORA_OCI_DEMO)/debu/noop TOT_CLIENT.C MSG_TIME, &context->remhost, &salen)) ) ........................^ %CC-E-UNDECLARED, In this statement, "MSG_TIME" is not declared. at line number 319 in file $1$DUA1130:[LAISHEV.DELTA.TOT]TOT_CLIENT.C;96 %MMK-F-ERRUPD, error status %X10B91262 occurred when updating target TOT_CLIENT.OBJ -------------------------------- Thanks. Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > >struct timeval tmo = {1,1}; > > > >if ( 0 > setsockopt (ctx.sockfd,SOL_SOCKET,SO_RCVTIMEO,&tmo,sizeof(tmo)) ) > >perror("setsockopt"); > >} > > > >setsockopt: non-translatable vms error code: 0x34C > [...] > > > > What is wrong ? > > > > $ exit %x34c > %SYSTEM-F-IVBUFLEN, invalid buffer length > > Table A-5 in the setsockopt documentation in the TCPware programmers guide: > > SO_RCVTIMEO > Sets the timeout value for datagram (UDP) sockets when the MSG_TIME flag > is used in socket_recv or recvfrom calls. The optval option is the > address of a short containing the timeout time (in seconds); optlen = > sizeof (short). The default value (set by socket) is 5 seconds. > ------------ > > struct timeval is 2 longs, so the size of struct timeval is 4 times the > size it should be. You should be passing in a short, the number of seconds > you want to set it to be. > > So if you want it to be 1 second, you'd want to have: > > u_short tmo; > tmo = 1; > > -Jeff > > -- +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Fri, 9 Jun 2000 16:19:13 -0400 Sender: schreiber@process.com Date: Fri, 9 Jun 2000 16:18:11 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB5B6.C5102E95.79@process.com> Subject: Re: SO_RCVTIMEO "Ruslan R. Laishev" writes: > >I see that PSC implementation is not compatible with "traditional" (*nix) >socket interface > Is this in reference to the receive timeout needing to be a short vs. a struct timeval? > MSG_TIME, &context->remhost, &salen)) ) >........................^ >%CC-E-UNDECLARED, In this statement, "MSG_TIME" is not declared. >at line number 319 in file $1$DUA1130:[LAISHEV.DELTA.TOT]TOT_CLIENT.C;96 >%MMK-F-ERRUPD, error status %X10B91262 occurred when updating target >TOT_CLIENT.OBJ Are you including socket.h? (Alcor)-> search tcpware_include:*.h msg_time ****************************** SYS$COMMON:[TCPWARE.INCLUDE]SOCKET.H;25 #define MSG_TIME 0x0100 /* limit receive wait time */ -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 9 Jun 2000 19:24:23 -0400 Return-Path: Message-ID: <39417B90.93638A0B@SMTP.DeltaTel.RU> Date: Sat, 10 Jun 2000 03:19:44 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: SO_RCVTIMEO Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > >I see that PSC implementation is not compatible with "traditional" (*nix) > >socket interface > > > > Is this in reference to the receive timeout needing to be a short vs. > a struct timeval? I planed writting portable code (the target platform is IBM OS/2) and I have found references to this socket option as COMPAQ specific (!!!) in the DEC TCPIP docs as well. Not big problem - it's just very pitty. I suspect also that PSC sockets API is different to DEC TCPIP socket API implementation also. Anyway, thanks for help Jeff! > > > MSG_TIME, &context->remhost, &salen)) ) > >........................^ > >%CC-E-UNDECLARED, In this statement, "MSG_TIME" is not declared. > >at line number 319 in file $1$DUA1130:[LAISHEV.DELTA.TOT]TOT_CLIENT.C;96 > >%MMK-F-ERRUPD, error status %X10B91262 occurred when updating target > >TOT_CLIENT.OBJ > > Are you including socket.h? :-) Yes. > > (Alcor)-> search tcpware_include:*.h msg_time I see. DEC C looking sys$library for headers, and I was ensuring that there was 100% compatibility between UCX (DEC TCPIP 5.x) and TCPWare. :( > > ****************************** > SYS$COMMON:[TCPWARE.INCLUDE]SOCKET.H;25 > > #define MSG_TIME 0x0100 /* limit receive wait time */ > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever -- +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Sat, 10 Jun 2000 08:54:53 -0400 Sender: schreiber@process.com Date: Sat, 10 Jun 2000 08:53:52 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB641.DD6844DD.20@process.com> Subject: Re: SO_RCVTIMEO "Ruslan R. Laishev" writes: > > I planed writting portable code (the target platform is IBM OS/2) and I >have found references to this socket option as COMPAQ specific (!!!) in >the DEC TCPIP docs as well. > > Not big problem - it's just very pitty. I suspect also that PSC sockets >API is different to DEC TCPIP socket API implementation also. > If you write the code using the DECC libraries and BG Devices, your executables should work fine between UCX and TCPware. It all depends on how you are doing it. I mean, if your trying to compile one using UCXs BGdevices, and one with TCPwares udp and tcp devices, it's going to be a little different. >> Are you including socket.h? > :-) Yes. >> > I see. DEC C looking sys$library for headers, and I was ensuring that >there was 100% compatibility between UCX (DEC TCPIP 5.x) and TCPWare. :( > So you need to ask compaq where the definition for MSG_TIME is. We provide it, they don't. If you do pure TCPware socket programming, you wouldn't have the problem, but trying to make it portable you're going to be using the DECC stuff yes? Basically, if you are going to use the socket features of the DECC library, then anything related to compile and linking issues have nothing to do with TCPWare, since it doesn't touch any of TCPware's parts. When you run it over BG devices, it will be hitting into TCPware's parts, and if it runs differently between tcpware and UCX, then that's our problem. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Sat, 10 Jun 2000 10:07:30 -0400 Return-Path: Message-ID: <39424A40.CE53D00D@SMTP.DeltaTel.RU> Date: Sat, 10 Jun 2000 18:01:36 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: SO_RCVTIMEO Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Thanks Jeff, for the explanation. Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > > I planed writting portable code (the target platform is IBM OS/2) and I > >have found references to this socket option as COMPAQ specific (!!!) in > >the DEC TCPIP docs as well. > > > > Not big problem - it's just very pitty. I suspect also that PSC sockets > >API is different to DEC TCPIP socket API implementation also. > > > > If you write the code using the DECC libraries and BG Devices, your > executables should work fine between UCX and TCPware. It all depends > on how you are doing it. I mean, if your trying to compile one using > UCXs BGdevices, and one with TCPwares udp and tcp devices, it's going > to be a little different. > > >> Are you including socket.h? > > :-) Yes. > >> > > I see. DEC C looking sys$library for headers, and I was ensuring that > >there was 100% compatibility between UCX (DEC TCPIP 5.x) and TCPWare. :( > > > > So you need to ask compaq where the definition for MSG_TIME is. We > provide it, they don't. If you do pure TCPware socket programming, > you wouldn't have the problem, but trying to make it portable you're > going to be using the DECC stuff yes? > > Basically, if you are going to use the socket features of the DECC > library, then anything related to compile and linking issues have > nothing to do with TCPWare, since it doesn't touch any of TCPware's > parts. When you run it over BG devices, it will be hitting into > TCPware's parts, and if it runs differently between tcpware and > UCX, then that's our problem. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever -- +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Mon, 12 Jun 2000 11:16:03 -0400 Message-ID: <3944FE68.24CFA4AF@PROCESS.COM> Date: Mon, 12 Jun 2000 11:14:48 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: Re: Cloned system has no Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Look at the Ethernet device configuration from the console level. It is > > important to know if you are connected to a 10 Mbit or 100 Mbit segment and have > > the ewa0_mode console variable configured appropriately. I believe that the > > accepted values are "twisted-pair" (10 Mbit), "Half-Duplex" or "Full-Duplex" > > (100Mbit). > > Not to create a distracting tangent to this thread, but it just so happens > that need to look up my machine's MAC address too. However I can't afford > to shut it down to look. Does anyone remember the DCL command to get it > with the system up? Thanks :) > $ MU ANAL/SYSTEM SHOW LAN/FULL its a few pages down. regards Mike -- +-------------------------------------------------------------------------+ 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, 12 Jun 2000 11:25:03 -0400 Message-ID: <39450088.EE9613A7@PROCESS.COM> Date: Mon, 12 Jun 2000 11:23:52 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: Re: Cloned system has no Network References: <3944FE68.24CFA4AF@PROCESS.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Corbett wrote: > > > > Look at the Ethernet device configuration from the console level. It is > > > important to know if you are connected to a 10 Mbit or 100 Mbit segment and have > > > the ewa0_mode console variable configured appropriately. I believe that the > > > accepted values are "twisted-pair" (10 Mbit), "Half-Duplex" or "Full-Duplex" > > > (100Mbit). > > > > Not to create a distracting tangent to this thread, but it just so happens > > that need to look up my machine's MAC address too. However I can't afford > > to shut it down to look. Does anyone remember the DCL command to get it > > with the system up? Thanks :) > > > > $ MU ANAL/SYSTEM > SHOW LAN/FULL Sometimes my fingers do there own thing. It should be $ ANAL/SYTEM and not $ MU ANAL/SYSTEM regards Mike -- +-------------------------------------------------------------------------+ 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: Wed, 14 Jun 2000 10:30:46 -0400 Message-ID: <394796B1.74428F7A@bsco.com> Date: Wed, 14 Jun 2000 10:29:05 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: "Info-TCPware@process.com" Subject: Duplicate IP Address Message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could someone explain the fields in Duplicate IP Message generated by TCPWare 5.4-3 and if it can be caused by other than a Duplicate IP ? Thanks -- Alan J. Kemmerer - alan.kemmerer@bsco.com Information Technology - Process Control Bethlehem Steel Corporation 410-388-7290 ================================================================================ Archive-Date: Wed, 14 Jun 2000 10:34:42 -0400 Sender: schreiber@process.com Date: Wed, 14 Jun 2000 10:33:35 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB974.7559546E.179@process.com> Subject: RE: Duplicate IP Address Message Alan Kemmerer writes: > >Could someone explain the fields in Duplicate IP Message generated by >TCPWare 5.4-3 >and if it can be caused by other than a Duplicate IP ? > If you could send an example of the message it would be much easier to find your answer. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 14 Jun 2000 10:46:03 -0400 Message-ID: <39479A46.4C9660A0@bsco.com> Date: Wed, 14 Jun 2000 10:44:22 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Duplicate IP Address Message References: <009EB974.7559546E.179@process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message from user TCPware(R) on NODE Duplicate IP address! ARP TIA: ZZZZZZZZ ARP SIA: YYYYYYYY ARP Source address AA-XX-XX-XX-XX-XX Ethernet Source address: AA-XX-XX-XX-XX-XX Ethernet Destination: FF-FF-FF-FF-FF-FF where YYYYYYYY = NODE (IP), Source address = NODE (DECNet) Jeff Schreiber wrote: > > Alan Kemmerer writes: > > > >Could someone explain the fields in Duplicate IP Message generated by > >TCPWare 5.4-3 > >and if it can be caused by other than a Duplicate IP ? > > > > If you could send an example of the message it would be much easier to > find your answer. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever -- Alan J. Kemmerer - alan.kemmerer@bsco.com Information Technology - Process Control Bethlehem Steel Corporation 410-388-7290 ================================================================================ Archive-Date: Wed, 14 Jun 2000 11:39:48 -0400 Sender: bryant@process.com Date: Wed, 14 Jun 2000 11:38:38 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009EB97D.8BC6CC82.182@process.com> Subject: Re: Duplicate IP Address Message A duplicate IP address should be the cause. This is seen because another system somewhere has responded to an ARP request for an address on the local system. Alan Kemmerer writes: > >Message from user TCPware(R) on NODE >Duplicate IP address! ARP TIA: ZZZZZZZZ ARP SIA: YYYYYYYY ARP Source >address AA-XX-XX-XX-XX-XX Ethernet Source address: AA-XX-XX-XX-XX-XX >Ethernet Destination: FF-FF-FF-FF-FF-FF > >where YYYYYYYY = NODE (IP), Source address = NODE (DECNet) > >Jeff Schreiber wrote: >> >> Alan Kemmerer writes: >> > >> >Could someone explain the fields in Duplicate IP Message generated by >> >TCPWare 5.4-3 >> >and if it can be caused by other than a Duplicate IP ? >> > >> >> If you could send an example of the message it would be much easier to >> find your answer. >> >> -Jeff >> >> -- >> Jeff Schreiber, Process Software Corp. >> schreiber@mx.process.com http://www.process.com >> TCPware & MultiNet: Stronger than Ever > >-- >Alan J. Kemmerer - alan.kemmerer@bsco.com >Information Technology - Process Control >Bethlehem Steel Corporation >410-388-7290 ------------------------------------------------------------- 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, 14 Jun 2000 11:50:05 -0400 Message-ID: <3947A946.E572BE02@bsco.com> Date: Wed, 14 Jun 2000 11:48:22 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Duplicate IP Address Message References: <009EB97D.8BC6CC82.182@process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What if it was not a duplicate IP ? Geoff Bryant wrote: > > A duplicate IP address should be the cause. This is seen because another > system somewhere has responded to an ARP request for an address on the local > system. > > Alan Kemmerer writes: > > > >Message from user TCPware(R) on NODE > >Duplicate IP address! ARP TIA: ZZZZZZZZ ARP SIA: YYYYYYYY ARP Source > >address AA-XX-XX-XX-XX-XX Ethernet Source address: AA-XX-XX-XX-XX-XX > >Ethernet Destination: FF-FF-FF-FF-FF-FF > > > >where YYYYYYYY = NODE (IP), Source address = NODE (DECNet) > > > >Jeff Schreiber wrote: > >> > >> Alan Kemmerer writes: > >> > > >> >Could someone explain the fields in Duplicate IP Message generated by > >> >TCPWare 5.4-3 > >> >and if it can be caused by other than a Duplicate IP ? > >> > > >> > >> If you could send an example of the message it would be much easier to > >> find your answer. > >> > >> -Jeff > >> > >> -- > >> Jeff Schreiber, Process Software Corp. > >> schreiber@mx.process.com http://www.process.com > >> TCPware & MultiNet: Stronger than Ever > > > >-- > >Alan J. Kemmerer - alan.kemmerer@bsco.com > >Information Technology - Process Control > >Bethlehem Steel Corporation > >410-388-7290 > > ------------------------------------------------------------- > Geoff Bryant bryant@process.com > TCPware/Multinet Engineering > Process Software Corporation http://www.process.com/ > 959 Concord St. > Framingham, MA 01701 USA -- Alan J. Kemmerer - alan.kemmerer@bsco.com Information Technology - Process Control Bethlehem Steel Corporation 410-388-7290 ================================================================================ Archive-Date: Wed, 14 Jun 2000 12:00:46 -0400 Return-Path: Subject: Re: Duplicate IP Address Message From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <3947aaff$1@news.kapsch.co.at> Date: 14 Jun 2000 17:55:43 +0200 To: Info-TCPware@PROCESS.COM In article <3947A946.E572BE02@bsco.com>, Alan Kemmerer writes: >What if it was not a duplicate IP ? Then it was a PROXY ARP feeding wrong info into the network... -- 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, 14 Jun 2000 14:58:26 -0400 Message-ID: <3947D56B.90874316@bsco.com> Date: Wed, 14 Jun 2000 14:56:43 -0400 From: Jim Dalsimer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com CC: Alan Kemmerer Subject: Re: [Fwd: Re: Duplicate IP Address Message] References: <3947A917.DA18D801@bsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The specific message we're getting is: Duplicate IP address! ARP TIA: 0AA8316D ARP SIA: 0AA8310C ARP Source address AA-00-04-00-2A-04 Ethernet Source: AA-00-04-00-2A-04 Ethernet Destination: FF-FF-FF-FF-FF-FF. The IP address of this machine is 10.168.49.12 and the Decnet address is 1.42. Which ethernet address is supposed to be the mac address of the "other" machine - or am I interpreting things wrong? Note that our network was acting strangely when this message was generated. We're trying to determine cause/effect. Alan Kemmerer wrote: > > -------- Original Message -------- > Subject: Re: Duplicate IP Address Message > Date: Wed, 14 Jun 2000 11:38:38 -0400 > From: Geoff Bryant > Reply-To: Info-TCPware@process.com > To: Info-TCPware@process.com > CC: bryant@process.com > > A duplicate IP address should be the cause. This is seen because > another > system somewhere has responded to an ARP request for an address on the > local > system. > > Alan Kemmerer writes: > > > >Message from user TCPware(R) on NODE > >Duplicate IP address! ARP TIA: ZZZZZZZZ ARP SIA: YYYYYYYY ARP Source > >address AA-XX-XX-XX-XX-XX Ethernet Source address: AA-XX-XX-XX-XX-XX > >Ethernet Destination: FF-FF-FF-FF-FF-FF > > > >where YYYYYYYY = NODE (IP), Source address = NODE (DECNet) > > > >Jeff Schreiber wrote: > >> > >> Alan Kemmerer writes: > >> > > >> >Could someone explain the fields in Duplicate IP Message generated by > >> >TCPWare 5.4-3 > >> >and if it can be caused by other than a Duplicate IP ? > >> > > >> > >> If you could send an example of the message it would be much easier to > >> find your answer. > >> > >> -Jeff > >> > >> -- > >> Jeff Schreiber, Process Software Corp. > >> schreiber@mx.process.com http://www.process.com > >> TCPware & MultiNet: Stronger than Ever > > > >-- > >Alan J. Kemmerer - alan.kemmerer@bsco.com > >Information Technology - Process Control > >Bethlehem Steel Corporation > >410-388-7290 > > ------------------------------------------------------------- > Geoff Bryant bryant@process.com > TCPware/Multinet Engineering > Process Software Corporation http://www.process.com/ > 959 Concord St. > Framingham, MA 01701 USA -- Jim Dalsimer - jedalsimer@bsco.com Information Technology - Process Control Bethlehem Steel Corporation 410-388-6204 ================================================================================ Archive-Date: Wed, 14 Jun 2000 15:11:55 -0400 Sender: schreiber@process.com Date: Wed, 14 Jun 2000 15:10:40 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB99B.2A7E0B39.10@process.com> Subject: Re: [Fwd: Re: Duplicate IP Address Message] Jim Dalsimer writes: > >The specific message we're getting is: > >Duplicate IP address! >ARP TIA: 0AA8316D >ARP SIA: 0AA8310C >ARP Source address AA-00-04-00-2A-04 >Ethernet Source: AA-00-04-00-2A-04 >Ethernet Destination: FF-FF-FF-FF-FF-FF. > >The IP address of this machine is 10.168.49.12 and the Decnet address is 1.42. >Which ethernet address is supposed to be the mac address of the "other" machine >- or am I interpreting things wrong? Note that our network was acting strangely >when this message was generated. We're trying to determine cause/effect. > I believe this is saying that this machine saw an ARP request looking for the MAC address of the device for the 10.168.49.109 IP address. When an ARP request is done, the sender puts in it's IP address and MAC address, so that members of the network can add that entry to their ARP cache as well. This machine saw an ARP request from a system that claimed to have the IP address that it has. In a nutshell, someone broadcasted an ARP request and said their IP address was the same as your system. The MAC address of the system with the Duplicate address is AA-00-04-00-2A-04. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 14 Jun 2000 15:27:18 -0400 Message-ID: <4.3.1.2.20000614132247.0150a720@mehlhop.org> Date: Wed, 14 Jun 2000 13:24:27 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: [Fwd: Re: Duplicate IP Address Message] In-Reply-To: <009EB99B.2A7E0B39.10@process.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:10 PM 6/14/00 -0400, you wrote: >Jim Dalsimer writes: > > > >The specific message we're getting is: > > > >Duplicate IP address! > >ARP TIA: 0AA8316D > >ARP SIA: 0AA8310C > >ARP Source address AA-00-04-00-2A-04 > >Ethernet Source: AA-00-04-00-2A-04 > >Ethernet Destination: FF-FF-FF-FF-FF-FF. > > > >The IP address of this machine is 10.168.49.12 and the Decnet address is > 1.42. > >Which ethernet address is supposed to be the mac address of the "other" > machine > >- or am I interpreting things wrong? Note that our network was acting > strangely > >when this message was generated. We're trying to determine cause/effect. > > > > I believe this is saying that this machine saw an ARP request looking > for the MAC address of the device for the 10.168.49.109 IP address. > > When an ARP request is done, the sender puts in it's IP address and MAC > address, so that members of the network can add that entry to their ARP > cache as well. > > This machine saw an ARP request from a system that claimed to have the > IP address that it has. In a nutshell, someone broadcasted an ARP > request > and said their IP address was the same as your system. > > The MAC address of the system with the Duplicate address is > AA-00-04-00-2A-04. Since this is a DECnet address you have 2 DEQ machines with the same DECnet address Jim > -Jeff > >-- >Jeff Schreiber, Process Software Corp. >schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever _________________________________________________________________________ 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, 14 Jun 2000 15:37:55 -0400 Message-ID: <4.3.1.2.20000614133150.01511860@mehlhop.org> Date: Wed, 14 Jun 2000 13:35:01 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: [Fwd: Re: Duplicate IP Address Message] In-Reply-To: <4.3.1.2.20000614132247.0150a720@mehlhop.org> References: <009EB99B.2A7E0B39.10@process.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:24 PM 6/14/00 -0600, you wrote: >At 03:10 PM 6/14/00 -0400, you wrote: >>Jim Dalsimer writes: >> > >> >The specific message we're getting is: >> > >> >Duplicate IP address! >> >ARP TIA: 0AA8316D >> >ARP SIA: 0AA8310C >> >ARP Source address AA-00-04-00-2A-04 >> >Ethernet Source: AA-00-04-00-2A-04 >> >Ethernet Destination: FF-FF-FF-FF-FF-FF. >> > >> >The IP address of this machine is 10.168.49.12 and the Decnet address >> is 1.42. >> >Which ethernet address is supposed to be the mac address of the "other" >> machine >> >- or am I interpreting things wrong? Note that our network was acting >> strangely >> >when this message was generated. We're trying to determine cause/effect. >> > >> >> I believe this is saying that this machine saw an ARP request looking >> for the MAC address of the device for the 10.168.49.109 IP address. >> >> When an ARP request is done, the sender puts in it's IP address and MAC >> address, so that members of the network can add that entry to their ARP >> cache as well. >> >> This machine saw an ARP request from a system that claimed to have the >> IP address that it has. In a nutshell, someone broadcasted an ARP >> request >> and said their IP address was the same as your system. >> >> The MAC address of the system with the Duplicate address is >> AA-00-04-00-2A-04. > >Since this is a DECnet address you have 2 DEQ machines with the same >DECnet address >Jim I didn't keep the previous posts but check the DECnet address of the system with IP address of 10.168.49.109 >> -Jeff >> >>-- >>Jeff Schreiber, Process Software Corp. >>schreiber@mx.process.com http://www.process.com >> TCPware & MultiNet: Stronger than Ever > > _________________________________________________________________________ > 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: Wed, 14 Jun 2000 17:02:16 -0400 Sender: root@plmlir5.mail.eds.com Message-ID: <3947F270.6FD559FE@bsco.com> Date: Wed, 14 Jun 2000 17:00:32 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: [Fwd: Re: Duplicate IP Address Message] References: <009EB99B.2A7E0B39.10@process.com> <4.3.1.2.20000614133150.01511860@mehlhop.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The host with ip 10.168.48.109 is a WinNT box it does not have a DECnet address. Jim Mehlhop wrote: > At 01:24 PM 6/14/00 -0600, you wrote: > >At 03:10 PM 6/14/00 -0400, you wrote: > >>Jim Dalsimer writes: > >> > > >> >The specific message we're getting is: > >> > > >> >Duplicate IP address! > >> >ARP TIA: 0AA8316D > >> >ARP SIA: 0AA8310C > >> >ARP Source address AA-00-04-00-2A-04 > >> >Ethernet Source: AA-00-04-00-2A-04 > >> >Ethernet Destination: FF-FF-FF-FF-FF-FF. > >> > > >> >The IP address of this machine is 10.168.49.12 and the Decnet address > >> is 1.42. > >> >Which ethernet address is supposed to be the mac address of the "other" > >> machine > >> >- or am I interpreting things wrong? Note that our network was acting > >> strangely > >> >when this message was generated. We're trying to determine cause/effect. > >> > > >> > >> I believe this is saying that this machine saw an ARP request looking > >> for the MAC address of the device for the 10.168.49.109 IP address. > >> > >> When an ARP request is done, the sender puts in it's IP address and MAC > >> address, so that members of the network can add that entry to their ARP > >> cache as well. > >> > >> This machine saw an ARP request from a system that claimed to have the > >> IP address that it has. In a nutshell, someone broadcasted an ARP > >> request > >> and said their IP address was the same as your system. > >> > >> The MAC address of the system with the Duplicate address is > >> AA-00-04-00-2A-04. > > > >Since this is a DECnet address you have 2 DEQ machines with the same > >DECnet address > >Jim > > I didn't keep the previous posts but check the DECnet address of the system > with IP address of 10.168.49.109 > > >> -Jeff > >> > >>-- > >>Jeff Schreiber, Process Software Corp. > >>schreiber@mx.process.com http://www.process.com > >> TCPware & MultiNet: Stronger than Ever > > > > _________________________________________________________________________ > > 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: Wed, 14 Jun 2000 17:19:22 -0400 Sender: schreiber@process.com Date: Wed, 14 Jun 2000 17:18:12 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EB9AC.FB740D2C.57@process.com> Subject: Re: [Fwd: Re: Duplicate IP Address Message] Alan Kemmerer writes: > > The host with ip 10.168.48.109 is a WinNT box it does not have a DECnet >address. > That host is the host that the problem box was trying to find the hardware address for... not the box with a problem. -Jeff ================================================================================ Archive-Date: Thu, 15 Jun 2000 09:20:51 -0400 Sender: goatley@triton.process.com Return-Path: Sender: root@plmlir5.mail.eds.com Message-ID: <3947F9CA.3AC46FC1@bsco.com> Date: Wed, 14 Jun 2000 17:31:54 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: [Fwd: Re: Duplicate IP Address Message] References: <009EB9AC.FB740D2C.57@process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could this have been caused by rebooting a switch that the target host was on ? ================================================================================ Archive-Date: Thu, 15 Jun 2000 09:29:25 -0400 Sender: schreiber@process.com Date: Thu, 15 Jun 2000 09:24:22 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EBA33.F41CD5EA.67@process.com> Subject: Re: [Fwd: Re: Duplicate IP Address Message] Alan Kemmerer writes: > >Could this have been caused by rebooting a switch that the target host >was on ? It shouldn't have anything to do with the target. The situation is that someone did an ARP request on your network. The system that did the arp request claimed to be the same IP address as the system that you saw the error message on. However the system that you saw the message on didn't have the same hardware address as the system that sent the ARP request, so the system that issued the message knows that it didn't issue the ARP request, and therefore there is someone out their with that specific hardware address, that is claiming they are the same IP address. -Jeff ================================================================================ Archive-Date: Thu, 15 Jun 2000 11:41:10 -0400 Message-ID: <3948F8AC.21F4EA07@bsco.com> Date: Thu, 15 Jun 2000 11:39:24 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Duplicate IP Address Message References: <3947aaff$1@news.kapsch.co.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Would this cause TCPware to generate a broadcast storm ? I have 372 identical "Duplicate IP Messages" over a time span of 1 min. in the operator.log Peter LANGSTOEGER wrote: > > In article <3947A946.E572BE02@bsco.com>, Alan Kemmerer writes: > >What if it was not a duplicate IP ? > > Then it was a PROXY ARP feeding wrong info into the network... > > -- > 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 -- Alan J. Kemmerer - alan.kemmerer@bsco.com Information Technology - Process Control Bethlehem Steel Corporation 410-388-7290 ================================================================================ Archive-Date: Fri, 16 Jun 2000 12:46:58 -0400 Return-Path: Subject: Re: Duplicate IP Address Message From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <394a4660@news.kapsch.co.at> Date: 16 Jun 2000 17:23:12 +0200 To: Info-TCPware@PROCESS.COM In article <3948F8AC.21F4EA07@bsco.com>, Alan Kemmerer writes: >Peter LANGSTOEGER wrote: >> In article <3947A946.E572BE02@bsco.com>, Alan Kemmerer writes: >> >What if it was not a duplicate IP ? >> >> Then it was a PROXY ARP feeding wrong info into the network... > >Would this cause TCPware to generate a broadcast storm ? >I have 372 identical "Duplicate IP Messages" over a time span of 1 min. >in the operator.log Don't think so. But, the question is, do you have a PROXY ARP server in use ? in TCPware syntax: Did you do $ NETCU ADD ARP/PUBLISH for anyone ? How about a SNIFFER, Bloodhound or similar tool and monitoring the net ? -- 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: Fri, 16 Jun 2000 13:33:31 -0400 Message-ID: <394A645E.5079ED3B@bsco.com> Date: Fri, 16 Jun 2000 13:31:10 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Duplicate IP Address Message References: <394a4660@news.kapsch.co.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The olny ARP entry that is PUBL in the ARP table is the host. We did not add any. We plan to try a controled test of the network sometime to see if a switch rebooting causes a loop in the network. Thanks for all your info. Peter LANGSTOEGER wrote: > > In article <3948F8AC.21F4EA07@bsco.com>, Alan Kemmerer writes: > >Peter LANGSTOEGER wrote: > >> In article <3947A946.E572BE02@bsco.com>, Alan Kemmerer writes: > >> >What if it was not a duplicate IP ? > >> > >> Then it was a PROXY ARP feeding wrong info into the network... > > > >Would this cause TCPware to generate a broadcast storm ? > >I have 372 identical "Duplicate IP Messages" over a time span of 1 min. > >in the operator.log > > Don't think so. > But, the question is, do you have a PROXY ARP server in use ? > in TCPware syntax: Did you do $ NETCU ADD ARP/PUBLISH for anyone ? > > How about a SNIFFER, Bloodhound or similar tool and monitoring the net ? > > -- > 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 -- Alan J. Kemmerer - alan.kemmerer@bsco.com Information Technology - Process Control Bethlehem Steel Corporation 410-388-7290 ================================================================================ Archive-Date: Tue, 20 Jun 2000 08:21:23 -0400 From: "Martin Vorlaender" Reply-To: Info-TCPware@process.com To: "TCPware Mailing List (E-Mail)" Subject: v5.2 SMTP config problem Date: Tue, 20 Jun 2000 14:23:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, we have a customer with the following problem: He has a VMS 5.5-2 system with TCPware 5.2. DNS is working (intra- and internet). His configuration includes SMTP_LOCALHOSTS -> local domain SMTP_RELAY -> UNKNOWN SMTP_RELAY_HOST -> IP address of the company gateway His intention was to deliver intra-company mail through this host, and forward everything else to the gateway. Local mail is delivered correctly. But (as TCPware can resolve all MX records) it looks like TCPware tries to deliver non-local mail directly - which doesn't work. How do you configure v5.2 SMTP to forward all non-local mail to the gateway? Does that version have this functionality at all? Thanks in advance for any hints, Martin -- OpenVMS: | Martin Vorlaender VMS & WNT programmer When you KNOW | work: mv@pdv-systeme.de where you want | http://www.pdv-systeme.de/users/martinv/ to go today. | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 20 Jun 2000 12:10:21 -0400 Return-Path: From: Andy Reply-To: Info-TCPware@process.com Subject: TCPware/TCPIP Services compatibility Date: Tue, 20 Jun 2000 15:20:34 GMT Message-ID: <8io23c$boc$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM It looks like we might be deploying one of our IP-based applications out to a customer site so they can do some testing against it. The trouble is that we're enlightened people who use TCPware & they're running Compaq's new TCP/IP Services V5.0A product. Now, I always thought that for 'basic' IP work TCPware was fully binary- compatible with UCX, and since Compaq say UCX is binary-compatible with TCP/IP Services we should be OK. However, one of our long-term developers remembers a conversation he had a few years ago with someone who said that there are subtle differences in some of the modifiers to some of the QIO functions. Can anyone from Process comment on this ? It'd be embarrassing if we put our application out there & it caused problems, but we don't have any available systems in-house at the moment where we can load up TCP/IP Services... Andy Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Tue, 20 Jun 2000 12:10:28 -0400 Return-Path: From: Andy Reply-To: Info-TCPware@process.com Subject: NETCU SHOW CONNECTION restriction Date: Tue, 20 Jun 2000 15:44:12 GMT Message-ID: <8io3g6$crk$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Our production systems currently run TCPWare V5.3-2 under VAX V6.2. We make heavy use of IP and appear to have hit the limit of NETCU's SHOW CONN command because we get about 512 TCP connections displayed followed by '???'. Nothing's mentioned in the NETCU command reference guide for V5.3-2 but I notice that the V5.4-3 book talks about a display limit of 1024 TCP connections. First question: Does V5.3-2 have a display limit of 512 connections ? Second question: Are there any plans to raise this limit from 1024 in a forthcoming release ? (The issue came to light because one of the checks the operators perform on a regular basis is a SHOW CONNECTION/REMOTE=xx to ensure that the current system does indeed have a working connection to the remote box. It's becoming increasingly more regular that they don't see one & hit the panic button, only to find the connection alive & well but living outside the display limit.) Cheers, -Andy Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Tue, 20 Jun 2000 13:05:54 -0400 Date: Tue, 20 Jun 2000 12:04:55 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: TCPware-Announce@PROCESS.COM, MultiNet-Announce@PROCESS.COM Message-ID: <000620120455.202000c2@goatley.com> Subject: MultiNet/TCPware TCP/IP Telebriefing Invitation Process Software invites all MultiNet and TCPware customers to participate in: Online MultiNet and TCPware TCP/IP TeleConference February 17, 2000 1--1:45pm EST Process Software's Senior Engineering and Product Marketing teams will bring you in-depth information on Secure Shell (SSH) technology which will be supported in the upcoming releases of MultiNet and TCPware and an update on the product roadmap. The teleconference will cover: - TCPware and MultiNet Product Roadmaps - Introduction on Process Software's Secure Shell SSH technology which provides strong authentication and secure communications over insecure channels - Question and answer period for participants Register now for the conference: http://www.process.com/tcpip/tcp_iptelebriefing.html ================================================================================ Archive-Date: Tue, 20 Jun 2000 13:13:15 -0400 Date: Tue, 20 Jun 2000 12:12:17 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: TCPware-Announce@PROCESS.COM, MultiNet-Announce@PROCESS.COM Message-ID: <000620121217.202000c2@goatley.com> Subject: Corrected announcement: MultiNet/TCPware TCP/IP Telebriefing Invitation CORRECTED DATE IS 29-JUN-2000!! Sorry about that. Process Software invites all MultiNet and TCPware customers to participate in: Online MultiNet and TCPware TCP/IP TeleConference JUNE 29, 2000 1--1:45 PM Process Software's Senior Engineering and Product Marketing teams will bring you in-depth information on Secure Shell (SSH) technology which will be supported in the upcoming releases of MultiNet and TCPware and an update on the product roadmap. The teleconference will cover: - TCPware and MultiNet Product Roadmaps - Introduction on Process Software's Secure Shell SSH technology which provides strong authentication and secure communications over insecure channels - Question and answer period for participants Register now for the conference: http://www.process.com/tcpip/tcp_iptelebriefing.html ================================================================================ Archive-Date: Tue, 20 Jun 2000 13:37:04 -0400 Sender: schreiber@process.com Date: Tue, 20 Jun 2000 13:35:34 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EBE44.DFB1D2D0.184@process.com> Subject: RE: TCPware/TCPIP Services compatibility Andy writes: > >Now, I always thought that for 'basic' IP work TCPware was fully binary- >compatible with UCX, and since Compaq say UCX is binary-compatible with >TCP/IP Services we should be OK. However, one of our long-term >developers remembers a conversation he had a few years ago with someone >who said that there are subtle differences in some of the modifiers to >some of the QIO functions. > >Can anyone from Process comment on this ? It'd be embarrassing if we >put our application out there & it caused problems, but we don't have >any available systems in-house at the moment where we can load up >TCP/IP Services... > If your application uses the BG device interface, you should be fine. If there are subtle differences, we would need to know about them, since there shouldn't be. If you are using something other than BG devices, the images probably won't work. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 20 Jun 2000 13:41:41 -0400 Sender: schreiber@process.com Date: Tue, 20 Jun 2000 13:40:10 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EBE45.8477B406.27@process.com> Subject: RE: NETCU SHOW CONNECTION restriction Andy writes: > >First question: Does V5.3-2 have a display limit of 512 connections ? > Yes, it was changed from 512 to 1024. The 512 limit was for TCP, and raised to 1024. The UDP limit was 256 and raised to 512. >Second question: Are there any plans to raise this limit from 1024 in a >forthcoming release ? It is being considered. I don't remember why I only changed it to 1024, and if there is a possible problem going larger than that. However I did have an inquiry recently, that made me consider bumping it up more. If it is something you feel strongly about, please put a request into Tech Support. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 20 Jun 2000 14:12:10 -0400 Sender: bryant@process.com Date: Tue, 20 Jun 2000 14:10:44 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009EBE49.C993A1E5.11@process.com> Subject: RE: TCPware/TCPIP Services compatibility We do have UCX compatablity with the BGDRIVER for QIOs and support for the C runtime libraries. We also have other APIs. Since you don't mention which APIs you are using, it is quite difficult to answer your question. Perhaps you should call into tech support so that this could be discussed in more detail. Andy writes: > >It looks like we might be deploying one of our IP-based applications >out to a customer site so they can do some testing against it. The >trouble is that we're enlightened people who use TCPware & they're >running Compaq's new TCP/IP Services V5.0A product. > >Now, I always thought that for 'basic' IP work TCPware was fully binary- >compatible with UCX, and since Compaq say UCX is binary-compatible with >TCP/IP Services we should be OK. However, one of our long-term >developers remembers a conversation he had a few years ago with someone >who said that there are subtle differences in some of the modifiers to >some of the QIO functions. > >Can anyone from Process comment on this ? It'd be embarrassing if we >put our application out there & it caused problems, but we don't have >any available systems in-house at the moment where we can load up >TCP/IP Services... > >Andy > > >Sent via Deja.com http://www.deja.com/ >Before you buy. > ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Tue, 20 Jun 2000 15:08:00 -0400 Return-Path: Subject: RE: TCPware/TCPIP Services compatibility From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <394fbb6a$1@news.kapsch.co.at> Date: 20 Jun 2000 20:43:54 +0200 To: Info-TCPware@PROCESS.COM In article <009EBE44.DFB1D2D0.184@process.com>, Jeff Schreiber writes: >Andy writes: >> >>Now, I always thought that for 'basic' IP work TCPware was fully binary- >>compatible with UCX, and since Compaq say UCX is binary-compatible with >>TCP/IP Services we should be OK. However, one of our long-term >>developers remembers a conversation he had a few years ago with someone >>who said that there are subtle differences in some of the modifiers to >>some of the QIO functions. >> >>Can anyone from Process comment on this ? It'd be embarrassing if we >>put our application out there & it caused problems, but we don't have >>any available systems in-house at the moment where we can load up >>TCP/IP Services... >> > > If your application uses the BG device interface, you should be fine. > If there are subtle differences, we would need to know about them, since > there shouldn't be. I see different behaviour with DCPS on TCPware and on UCX, though GENICOM claims that they previously didn't support TCPware at all but now do via the UCX compatibility mode (I think, this is what you call the BG device). Most of the time it works, but some unsupported printer queues do not work at all with TCPware but work as unsupported printer without problems on UCX. If I finally find the time, to go into detail, I will let you and GENICOM know, what network traffic differences I found... just my 0.02 -- 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: Tue, 20 Jun 2000 17:30:22 -0400 Return-Path: Message-ID: <394FD10B.BC71435E@SMTP.DeltaTel.RU> Date: Wed, 21 Jun 2000 00:16:11 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPware/TCPIP Services compatibility Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM I have discovered one compatibility problem, see my post with subject:"BINDIG an UDP socket (DEC TCPIP & PSC MULTINET/TCPWARE)" UCX engineering was going to silence. :-( Andy wrote: > > It looks like we might be deploying one of our IP-based applications > out to a customer site so they can do some testing against it. The > trouble is that we're enlightened people who use TCPware & they're > running Compaq's new TCP/IP Services V5.0A product. > > Now, I always thought that for 'basic' IP work TCPware was fully binary- > compatible with UCX, and since Compaq say UCX is binary-compatible with > TCP/IP Services we should be OK. However, one of our long-term > developers remembers a conversation he had a few years ago with someone > who said that there are subtle differences in some of the modifiers to > some of the QIO functions. > > Can anyone from Process comment on this ? It'd be embarrassing if we > put our application out there & it caused problems, but we don't have > any available systems in-house at the moment where we can load up > TCP/IP Services... > > Andy > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Tue, 20 Jun 2000 21:23:24 -0400 Date: Tue, 20 Jun 2000 20:22:13 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-MultiNet@process.com, Info-TCPware@process.com Message-ID: <000620202213.202000c2@goatley.com> Subject: More info on MultiNet/TCPware Telebriefing A number of people have written with various questions about the telebriefing. I'll try to summarize those answers here. - The correct date for the telebriefing is Thursday, 29-JUN-2000. I posted the date of the last telebriefing to see if everyone was awake. Everyone was. One person said I was living in the past. I like it that way---it's nice and predictable. - The telebriefing is scheduled from 1:00 to 1:45 PM EDT (GMT - 4:00). - The telebriefing is telephone-based. You'll call into a moderated presentation by Process Software. There will be an opportunity to ask questions at the end of the briefing. - There will be an 800 number of US customers and a different number for non-US customers to call. The numbers will be e-mailed to you after you fill out the registration form: http://www.process.com/tcpip/tcp_iptelebriefing.html - A PowerPoint presentation to accompany the telebriefing will be available for download. Web-based pages will also be available. Registrants will be notified with URLs before the telebriefing. - We plan for the telebriefing to be available for replay by telephone for at least a week after the briefing. - Hopefully within a week or two of the briefing, it'll be available as a streaming RealAudio file from our web site. That's the plan.... - About the web site: yes, we know it still doesn't work with Netscape V3.03. We're working on it. We have removed a lot of what didn't work (it no longer sends you to Netscape.com), and we're continuing to work to make it friendly to VMS browsers. It may take a little time, so please bear with us while we undo some of what was done before the acquisition. Thanks for choosing TCPware and MultiNet! Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Wed, 21 Jun 2000 09:42:10 -0400 Message-ID: From: "Walsh, William M" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: More info on MultiNet/TCPware Telebriefing Date: Wed, 21 Jun 2000 06:40:22 -0700 MIME-Version: 1.0 Content-Type: text/plain Hunter, I am a Boeing employee in Seattle. I have been asked to gather a little information about the 6/29/2000 TCP/IP teleconference. Could/would you give me a brief (3 sentence) overview of the content/purpose of the teleconference? I am trying to determine if it will be of value to members my organization. Thank you. Sincerely, William M. Walsh (425) 234-0604 Org: 6-6E26 M/S 6C-FH (7-42.2 bldg.) e-mail:william.m.walsh@boeing.com > ---------- > From: Hunter Goatley[SMTP:goathunter@PROCESS.COM] > Reply To: Info-TCPware@process.com > Sent: Tuesday, June 20, 2000 18:22 > To: Info-MultiNet@process.com; Info-TCPware@process.com > Subject: More info on MultiNet/TCPware Telebriefing > > A number of people have written with various questions about the > telebriefing. I'll try to summarize those answers here. > > - The correct date for the telebriefing is Thursday, 29-JUN-2000. > > I posted the date of the last telebriefing to see if everyone > was awake. Everyone was. > > One person said I was living in the past. I like it that > way---it's nice and predictable. > > - The telebriefing is scheduled from 1:00 to 1:45 PM EDT > (GMT - 4:00). > > - The telebriefing is telephone-based. You'll call into a > moderated presentation by Process Software. There will be an > opportunity to ask questions at the end of the briefing. > > - There will be an 800 number of US customers and a different > number for non-US customers to call. > > The numbers will be e-mailed to you after you fill out the > registration form: > > http://www.process.com/tcpip/tcp_iptelebriefing.html > > - A PowerPoint presentation to accompany the telebriefing will > be available for download. Web-based pages will also be > available. Registrants will be notified with URLs before > the telebriefing. > > - We plan for the telebriefing to be available for replay by > telephone for at least a week after the briefing. > > - Hopefully within a week or two of the briefing, it'll be > available as a streaming RealAudio file from our web site. > That's the plan.... > > - About the web site: yes, we know it still doesn't work with > Netscape V3.03. We're working on it. We have removed a lot > of what didn't work (it no longer sends you to Netscape.com), > and we're continuing to work to make it friendly to VMS browsers. > It may take a little time, so please bear with us while we undo > some of what was done before the acquisition. > > Thanks for choosing TCPware and MultiNet! > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www.goatley.com/hunter/ > ================================================================================ Archive-Date: Wed, 21 Jun 2000 09:58:25 -0400 Date: Wed, 21 Jun 2000 8:57:28 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: WILLIAM.WALSH@PSS.BOEING.COM Message-ID: <000621085728.202000c2@goatley.com> Subject: RE: More info on MultiNet/TCPware Telebriefing "Walsh, William M" writes: > >Hunter, >I am a Boeing employee in Seattle. I have been asked to gather a little information about the 6/29/2000 TCP/IP teleconference. Could/would you give me a brief (3 sentence) overview of the content/purpose of the teleconference? I am trying to determine >if it will be of value to members my organization. Thank you. This is from the original announcement >Process Software's Senior Engineering and Product Marketing teams will >bring you in-depth information on Secure Shell (SSH) technology which >will be supported in the upcoming releases of MultiNet and TCPware and >an update on the product roadmap. The teleconference will cover: > >- TCPware and MultiNet Product Roadmaps >- Introduction on Process Software's Secure Shell SSH technology which > provides strong authentication and secure communications over insecure > channels >- Question and answer period for participants That basically sums it up. There'll be a presentation/discussion about SSH (in MultiNet V4.3 and the next TCPware release), as well as a look at the roadmaps for both products. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Wed, 21 Jun 2000 11:50:57 -0400 Return-Path: From: Andy Reply-To: Info-TCPware@process.com Subject: RE: NETCU SHOW CONNECTION restriction Date: Wed, 21 Jun 2000 15:29:10 GMT Message-ID: <8iqmvd$a4p$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Thanks Jeff. Yes, I'll put a request in. We're currently running at around 800 per main VAX system (adding up all the INET and BG devices) but we're contemplating moving to Alpha & consolidating 3 VAX systems to one Alpha. That'll almost certainly blow the 1024 limit. Cheers, -Andy In article <009EBE45.8477B406.27@process.com>, Jeff Schreiber wrote: > Andy writes: > > > >First question: Does V5.3-2 have a display limit of 512 connections ? > > > > Yes, it was changed from 512 to 1024. The 512 limit was for TCP, and > raised to 1024. The UDP limit was 256 and raised to 512. > > >Second question: Are there any plans to raise this limit from 1024 in a > >forthcoming release ? > > It is being considered. I don't remember why I only changed it to 1024, > and if there is a possible problem going larger than that. However I did > have an inquiry recently, that made me consider bumping it up more. If > it is something you feel strongly about, please put a request into Tech > Support. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever > > Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Wed, 21 Jun 2000 13:34:51 -0400 Date: Wed, 21 Jun 2000 13:32:59 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P090 To: TCPware-Announce@PROCESS.COM Message-ID: <01JQV7EF2SW2005Y9B@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: FTP_V543P090 Description: Various FTP client and server fixes Release date: 21-JUN-2000 Ranking: Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p090.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. ----------------------------------------------------------- ----------------------------------------------------------------------- FTP Patch kit (revision 9.0) for TCPware version 5.4-3 19-Jun-2000 Copyright (c) 2000, by Process Software Corporation This VMSinstallable saveset provides a new versions of FTP_CONTROL.COM, FTP_LISTENER.EXE, and FTP_SERVER.EXE for TCPware for OpenVMS. TCPWare V5.4-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made in this kit: FTP.EXE - Check a new logical (TCPWARE_FTP_LOWERCASE_USERNAME), which when defined as True, Yes, or 1 will make the username, password and account lowercase before they are sent to the remote system if the username was prompted for. (DE 6264) This allows behavior from earlier versions of TCPware FTP to be optionally restored. ECO FTP_V543P090 rank 3 FTP_SERVER.EXE - Fix a problem with TCPWARE_FTP_IDLE_TIMEOUT being set to 0 (zero) causing immediate timeouts. (DE 6288) Note that Process Software recommends that this value not be set to 0, as it can cause resources to be tied up on your system. ECO FTP_V543P090 rank 3 FTP_LISTENER.EXE - Fix a problem with the change in FTP_V543P080 that makes FTP_LISTENER use a lot of buffered I/O byte count quota. (DE6290) Because the reverse lookups were left pending after the program had given up on them there would buffered I/O byte count quota in use for longer than necessary. If the server was busy the available quota would get consumed quicker than the pending requests would complete. ECO FTP_V543P090 rank 3 The following changes from previous kits also in this kit: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) ECO FTP_V543P010 rank 3. FTP_LISTENER.EXE - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) ECO FTP_V543P010 rank 3. - A possible denial of service attack has been corrected. (DE 5347) To control how much time can elapse before the connection is killed if it is not successfully authorized as an FTP user define TCPWARE_FTP_IDLE_TIMEOUT. The format for this logical is the delta time (dddd hh:mm:ss.hh) that can elapse between when the connection is established and when it must be successfully logged in. The default value for this is 10 minutes. ECO FTP_V543P020 rank 2. - Correct a problem with FTP_V543P030 that could cause the TCPware_FTP process to consume channels. ECO FTP_V543P040 rank 2. - Problems looking up the host name for a new connection could stall all connections when one of them provided authorization information. The code has been modified so that the logical TCPWARE_FTP_GETHOST_MAX_TIME can be used to control how long it will attempt to translate the name before it gives up. TCPWARE_FTP_GETHOST_MAX_TIME is specified as a VMS delta time, and has a default value of 10 seconds. (DE 6262) ECO FTP_V543P080, rank 3. FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) ECO FTP_V543P010 rank 3. - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) ECO FTP_V543P010 rank 3. - A data corruption problem has been corrected. (DE 5298) ECO FTP_V543P020 rank 2. - When the logical TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC is defined to TRUE files with variable length records and carriage return carriage control will NOT have a new line character inserted after each line when the file is transfered in image (binary) mode. This logical is now defined to be TRUE by default in FTPSERVER_DTP.COM, returning to the behavior present in TCPWare 5.3 (DE 5709) ECO FTP_V543P030 rank 3. - Correct a problem that can occur when deleting files on a VAX from an NT system where the error "%LIB-F-INVSTRDES, invalid string descriptor" could occur. (DE 5722) ECO FTP_V543P040 rank 3. - Correct a problem when TCPWARE_FTP__ROOT is defined to be disk:[dir.] /translation=conceal that would cause the user to be denied access to directories that previous versions of FTP did not deny access to. (DE5670) ECO FTP_V543P040 rank 3. - Correct a problem with deleting wildcarded files in Unix mode. (DE 5734) ECO FTP_V543P040 rank 3. - Correct a problem with displaying the directory in the 150 reply message in Unix mode. (DE 5736) ECO FTP_V543P040 rank 3. - Correct a problem with the /IMAGE=size qualifier on the target file of a PUT command. (DE 6055) ECO FTP_V543P050 rank 3. - Correct a problem with recognizing that TCPWARE_FTP__ROOT being defined as * means no restrictions. (DE 6058) ECO FTP_V543P050 rank 3. - Allow /IMAGE=size to write out files with fixed length records of other than 512 bytes (DE 6055) ECO FTP_V543P060 rank 3. - There was a discrepency between the documentation and the code on how to disable Unix syntax in the FTP server. The documentation specified the logical TCPWARE_FTP_DISALLOW_UNIX_STYLE and the code checked for TCPWARE_FTPD_NOUNIX_SYNTAX. The code has been modified to check for both logicals. Note that the FTP server startup procedure defines TCPWARE_FTP_DISALLOW_UNIX_STYLE to TRUE if it is not already defined. If you want UNIX style directories to be enabled you must define TCPWARE_FTP_DISALLOW_UNIX_STYLE to FALSE. This can be done at either the system or user level. (DE 6219) ECO FTP_V543P070, rank 3. After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 22 Jun 2000 10:23:15 -0400 Sender: schreiber@process.com Date: Thu, 22 Jun 2000 10:21:40 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EBFBC.1E7A104B.8@process.com> Subject: RE: NETCU SHOW CONNECTION restriction Jeff Schreiber writes: > If it is something you feel strongly about, please put a request into > Tech Support. I may have made an improper assumption. I should have said "please put a request into Tech Support, or your distributor if you are an international customer". Since we are mostly engineers, we generally forget the logistics of the business. So if you are an international customer, please assume that if we say "log with support", we are inferring that support means whoever you are officially setup to use for support. -Jeff ================================================================================ Archive-Date: Thu, 22 Jun 2000 18:38:51 -0400 Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A68C1F@ntprdex4.admin.liffe.com> From: Andy Williams Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NETCU SHOW CONNECTION restriction Date: Thu, 22 Jun 2000 23:37:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Jeff. I logged it both with your support desk and with our UK supplier (Essential Computing). Cheers, > Andy Williams > OpenVMS System Specialist > Andy.Williams@LIFFE.com > +44 (0)20 7379 2581 > -----Original Message----- From: Jeff Schreiber [mailto:schreiber@process.com] Sent: Thursday, June 22, 2000 3:22 PM To: Info-TCPware@process.com Cc: schreiber@process.com Subject: RE: NETCU SHOW CONNECTION restriction *********************************************************************** 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. *********************************************************************** Jeff Schreiber writes: > If it is something you feel strongly about, please put a request into > Tech Support. I may have made an improper assumption. I should have said "please put a request into Tech Support, or your distributor if you are an international customer". Since we are mostly engineers, we generally forget the logistics of the business. So if you are an international customer, please assume that if we say "log with support", we are inferring that support means whoever you are officially setup to use for support. -Jeff ---------------------------------------------------------------------- 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: Mon, 26 Jun 2000 10:52:27 -0400 Date: Mon, 26 Jun 2000 9:50:28 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-MultiNet@process.com, Info-TCPware@process.com Message-ID: <000626095028.202000c3@goatley.com> Subject: Reminder: Process Software telebriefing on 29-JUN-2000 I was asked to remind you: >Process Software invites all MultiNet and TCPware customers to >participate in: > > Online MultiNet and TCPware TCP/IP TeleConference > 29-JUN-2000 > 1--1:45 PM EDT > >Process Software's Senior Engineering and Product Marketing teams will >bring you in-depth information on Secure Shell (SSH) technology which >will be supported in the upcoming releases of MultiNet and TCPware and >an update on the product roadmap. The teleconference will cover: > >- TCPware and MultiNet Product Roadmaps >- Introduction on Process Software's Secure Shell SSH technology which > provides strong authentication and secure communications over insecure > channels >- Question and answer period for participants > >Register now for the conference: > > http://www.process.com/tcpip/tcp_iptelebriefing.html All registrants will receive the presentation via e-mail by Tuesday. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Mon, 26 Jun 2000 11:06:00 -0400 Message-ID: <395770D9.8D1C49AF@mmaz.com> Date: Mon, 26 Jun 2000 08:03:53 -0700 From: "Barry Treahy, Jr." Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Reminder: Process Software telebriefing on 29-JUN-2000 References: <000626095028.202000c3@goatley.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hunter, was any consideration made of my requests months past regarding Purveyor? Just to jog your memory, it was my understanding that it is no longer an active product and had been discontinued. I had requested that Process consider placing the sources into public domain as an alternative to OSU and others... Regards, Barry Hunter Goatley wrote: > I was asked to remind you: > > >Process Software invites all MultiNet and TCPware customers to > >participate in: > > > > Online MultiNet and TCPware TCP/IP TeleConference > > 29-JUN-2000 > > 1--1:45 PM EDT > > > >Process Software's Senior Engineering and Product Marketing teams will > >bring you in-depth information on Secure Shell (SSH) technology which > >will be supported in the upcoming releases of MultiNet and TCPware and > >an update on the product roadmap. The teleconference will cover: > > > >- TCPware and MultiNet Product Roadmaps > >- Introduction on Process Software's Secure Shell SSH technology which > > provides strong authentication and secure communications over insecure > > channels > >- Question and answer period for participants > > > >Register now for the conference: > > > > http://www.process.com/tcpip/tcp_iptelebriefing.html > > All registrants will receive the presentation via e-mail by Tuesday. > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www.goatley.com/hunter/ -- Barry Treahy, Jr * Midwest Microwave * Vice President & CIO E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028 ================================================================================ Archive-Date: Mon, 26 Jun 2000 11:09:31 -0400 Sender: schreiber@process.com Date: Mon, 26 Jun 2000 11:07:49 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009EC2E7.3A6CDBC4.314@process.com> Subject: Re: Reminder: Process Software telebriefing on 29-JUN-2000 "Barry Treahy, Jr." writes: > >Hunter, was any consideration made of my requests months past regarding >Purveyor? Just to jog your memory, it was my understanding that it is no >longer an active product and had been discontinued. I had requested that >Process consider placing the sources into public domain as an alternative to >OSU and others... > You are not the only one requesting something along the lines of this. It is not something that has been forgotten, although I don't know at this time where we are in a decision [aside of it being in the management clouds above my head :) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 26 Jun 2000 11:10:36 -0400 Date: Mon, 26 Jun 2000 10:08:33 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000626100833.202000c3@goatley.com> Subject: Re: Reminder: Process Software telebriefing on 29-JUN-2000 "Barry Treahy, Jr." writes: > >Hunter, was any consideration made of my requests months past regarding >Purveyor? Just to jog your memory, it was my understanding that it is no >longer an active product and had been discontinued. I had requested that >Process consider placing the sources into public domain as an alternative to >OSU and others... > Yes, that has been discussed. Frankly, I'm not exactly sure what we're doing with Purveyor. I'll check on that again today and try to reply here. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Mon, 26 Jun 2000 11:21:13 -0400 Message-ID: From: "Johnston, Julie" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: Restarting Multinet Date: Mon, 26 Jun 2000 08:10:37 -0700 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === Has anyone had any problems with restarting multinet? I made some changes to my SMTP config and ran the start_smtp, and start_server and changes did not take affect... I'd hate to have to reboot. I have VMS 7.2 Multinet 4.2 Thanks.. Julie Johnston Systems Administration REMEC, Inc. ================================================================================ Archive-Date: Mon, 26 Jun 2000 11:24:12 -0400 Sender: schreiber@process.com Date: Mon, 26 Jun 2000 11:22:25 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: info-multinet@process.com, schreiber@process.com Message-ID: <009EC2E9.44E436D6.71@process.com> Subject: RE: Restarting Multinet "Johnston, Julie" writes: > >Has anyone had any problems with restarting multinet? I made some changes >to my SMTP config and ran the >start_smtp, and start_server and changes did not take affect... I'd hate to >have to reboot. I have VMS 7.2 >Multinet 4.2 > Julie, Can you give a little more details to what you did. And perhaps you should use the info-multinet@process.com [vmsnet.networks.tcpip.multinet] mailing list [newsgroup]. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 26 Jun 2000 14:21:32 -0400 Message-ID: <20000626182123.6448.qmail@venus.postmark.net> MIME-Version: 1.0 From: yottabit Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: DNS CNAME question Date: Mon, 26 Jun 2000 12:21:23 -0600 Content-Type: text/plain; charset="iso-8859-1" Hi, Using TCPware(R) for OpenVMS V5.3-3 Copyright (c) 1998 Process Software Corporation In our setup, we are using two Cisco Distributed Directors which are running DNS for wsf.abc.com. I want "www.def.com" AND just "def.com" to go to wsf.abc.com. I would also like "abc.com" to go to wsf.abc.com and not have the A record of 192.168.100.1. The whole point of using the directors is so that a location can go down and requests for the domain will go to the other location. With the configs below, someone going to www.abc.com will "bounce" between the two DDs, but if they go to abc.com, and the 192.168.100 location happens to be down, they don't get anywhere. I know I could make a wsf entry for def.com in the DDs, but I have many domains that need to be setup also. If I change the A record for def.com in that zone file to a "CNAME wsf.abc.com" record and reload DNS, named will issue several illegal record errors, but doing an NSLOOKUP works for def.com then seems to work okay. I know that's not correct. I tried looking this type of thing up in _DNS and Bind_ but couldn't find anything... maybe I missed it? Is there a better way to set this up? Thanks for any help! Chris ---------------- DNS zone file for ABC.COM: @ IN SOA ns1.abc.com. hostmaster.abc.com. ( 2000012223 ; Serial 10800 ; Refresh 3 hrs 3601 ; Retry 1hr 259200 ; Expire 3 days 21600 ) ; Minimum TTL 6 hrs abc.com. A 192.168.100.1 www CNAME wsf.abc.com. ; these DDs are in two separate locations on different networks dd A 192.168.100.10 A 192.168.200.10 wsf 0 IN NS dd.abc.com. ---------------- DNS zone file for DEF.COM: @ IN SOA ns1.abc.com. hostmaster.abc.com. ( 2000012223 ; Serial 10800 ; Refresh 3 hrs 3601 ; Retry 1hr 259200 ; Expire 3 days 21600 ) ; Minimum TTL 6 hrs def.com. A 192.168.100.2 www CNAME wsf.abc.com. --- ================================================================================ Archive-Date: Tue, 27 Jun 2000 02:42:32 -0400 From: "Martin Vorlaender" Reply-To: Info-TCPware@process.com To: , Subject: RE: Reminder: Process Software telebriefing on 29-JUN-2000 Date: Tue, 27 Jun 2000 08:44:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <000626095028.202000c3@goatley.com> > I was asked to remind you: > > >Process Software invites all MultiNet and TCPware customers to > >participate in: > > > > Online MultiNet and TCPware TCP/IP TeleConference > > 29-JUN-2000 > > 1--1:45 PM EDT On the web site it says 1pm EST... To end this confusion, couldn't you just give the numeric timezone (-0400?) ? :-) I suppose that would be 7pm MESZ (Middle European Daylight Savings Time, +0200). cu, Martin -- One OS to rule them all | Martin Vorlaender | VMS & WNT programmer One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://www.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 27 Jun 2000 08:41:36 -0400 Date: Tue, 27 Jun 2000 7:39:45 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: Info-MultiNet@process.com Message-ID: <000627073945.202000c2@goatley.com> Subject: RE: Reminder: Process Software telebriefing on 29-JUN-2000 "Martin Vorlaender" writes: > >> > Online MultiNet and TCPware TCP/IP TeleConference >> > 29-JUN-2000 >> > 1--1:45 PM EDT > >On the web site it says 1pm EST... To end this confusion, >couldn't you just give the numeric timezone (-0400?) ? :-) > GMT -0400 it is! >I suppose that would be 7pm MESZ (Middle European Daylight Savings Time, >+0200). > Yes. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Tue, 27 Jun 2000 14:38:51 -0400 From: "Lutes, Dale" Reply-To: Info-TCPware@process.com To: Info-TCPware Message-ID: <3958ADEB.759F3EBD@cessna.textron.com> Date: Tue, 27 Jun 2000 13:36:43 -0500 MIME-Version: 1.0 Subject: SMTP configuration question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm sure the answer is simple, but I'm just missing it somehow. My company's e-mail is handled by a MicroSoft Exchange server. I am able to receive mail directly into my VMS mail file. Using Netscape on my VMS system, I can send mail via the Exchange server, but for some reason I am unable to send from VMS mail. This only affects addresses outside of our company mail system. I have no problem with either method for internal mail. Here are the SMTP parameters from TCPWARE_CONFIGURE.COM. Any suggestions? $! *** SMTP-OpenVMS parameters *** $ SMTP_ENABLE == 1 $ SMTP_POSTMASTER == "SYSTEM" $ SMTP_SERVERS == 1 $ SMTP_CLIENTS == 1 $ SMTP_CONNECT_TIMEOUT == "0 00:02:00" $ SMTP_CHECK_INTERVAL == "0 00:30:00" $ SMTP_RETRY_INTERVAL == "0 00:30:00" $ SMTP_MSG_LIFE == "5 00:00:00" $ SMTP_MAX_ADDR == 8 $ SMTP_MAXHOP == 32 $ SMTP_VRFY_ENABLE == 1 $ SMTP_DISKQUOTA == "IGNORE" $ SMTP_RET_REC_TO_ENABLE == 1 $ SMTP_LOCALHOSTS == "" $ SMTP_FROM_DOMAIN == "tds.cessna.textron.com" $ SMTP_RELAY == "UNKNOWN" $ SMTP_RELAY_HOST == "cess01amx04.cessna.textron.com" $ SMTP_MRHOST == "" $ SMTP_A1MBX == "" $ SMTP_RETURN_MSG == "SMTP_RETURN_MSG.TXT" $ SMTP_MAILING_LIST == "TCPWARE_COMMON:[TCPWARE.MAILING_LIST]" $ SMTP_SYSTEM_HEADER_ORG == "Cessna Aircraft Company" $ SMTP_SYSTEM_HEADER_SYS == "" -- Dale D. Lutes Flight Data Systems Cessna Aircraft Company 316-517-7109 ================================================================================ Archive-Date: Wed, 28 Jun 2000 09:59:06 -0400 Message-ID: <395A0433.4D659ABB@PROCESS.COM> Date: Wed, 28 Jun 2000 09:57:07 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com, dlutes@cessna.textron.com Subject: RE: SMTP configuration question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > I'm sure the answer is simple, but I'm just missing it somehow. > > My company's e-mail is handled by a MicroSoft Exchange server. > I am able to receive mail directly into my VMS mail file. Using > Netscape on my VMS system, I can send mail via the Exchange > server, but for some reason I am unable to send from VMS mail. > This only affects addresses outside of our company mail system. > I have no problem with either method for internal mail. > > Here are the SMTP parameters from TCPWARE_CONFIGURE.COM. > Any suggestions? > > $! *** SMTP-OpenVMS parameters *** > $ SMTP_ENABLE == 1 > $ SMTP_POSTMASTER == "SYSTEM" > $ SMTP_SERVERS == 1 > $ SMTP_CLIENTS == 1 > $ SMTP_CONNECT_TIMEOUT == "0 00:02:00" > $ SMTP_CHECK_INTERVAL == "0 00:30:00" > $ SMTP_RETRY_INTERVAL == "0 00:30:00" > $ SMTP_MSG_LIFE == "5 00:00:00" > $ SMTP_MAX_ADDR == 8 > $ SMTP_MAXHOP == 32 > $ SMTP_VRFY_ENABLE == 1 > $ SMTP_DISKQUOTA == "IGNORE" > $ SMTP_RET_REC_TO_ENABLE == 1 > $ SMTP_LOCALHOSTS == "" > $ SMTP_FROM_DOMAIN == "tds.cessna.textron.com" > $ SMTP_RELAY == "UNKNOWN" > $ SMTP_RELAY_HOST == "cess01amx04.cessna.textron.com" > $ SMTP_MRHOST == "" > $ SMTP_A1MBX == "" > $ SMTP_RETURN_MSG == "SMTP_RETURN_MSG.TXT" > $ SMTP_MAILING_LIST == "TCPWARE_COMMON:[TCPWARE.MAILING_LIST]" > $ SMTP_SYSTEM_HEADER_ORG == "Cessna Aircraft Company" > $ SMTP_SYSTEM_HEADER_SYS == "" > Dale, Without knowing what sort of error you get when sending the mail this is just a guess - I would try changing the SMTP_RELAY from UNKNOWN to all. This will send all SMTP mail to cess01amx04.cessna.textron.com and then that system should forward it to the appropriate destination. With SMTP_RELAY set to "UNKNOWN" it is only going to send messages with addresses that it can not resolve to the forwarder and everything else it will try to send itself. So if the system can resolve DNS names but can not reach the internet then you want SMTP_RELAY to be ALL and not UNKNOWN. Hope that helps Mike -- +-------------------------------------------------------------------------+ 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: Wed, 28 Jun 2000 11:15:24 -0400 From: "Lutes, Dale" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <3959CFBD.32021E14@cessna.textron.com> Date: Wed, 28 Jun 2000 10:13:17 -0500 MIME-Version: 1.0 Subject: Re: SMTP configuration question References: <395A0433.4D659ABB@PROCESS.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Corbett wrote: > ... > Dale, > > Without knowing what sort of error you get when sending the mail > this is just a guess - I would try changing the SMTP_RELAY from UNKNOWN > to all. This will send all SMTP mail to cess01amx04.cessna.textron.com > and then that system should forward it to the appropriate destination. With > SMTP_RELAY set to "UNKNOWN" it is only going to send messages with addresses > that it can not resolve to the forwarder and everything else it will try to send > itself. So if the system can resolve DNS names but can not reach the internet > then you want SMTP_RELAY to be ALL and not UNKNOWN. > > Hope that helps > Mike > > -- > +-------------------------------------------------------------------------+ > 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 Thanks, Mike, That was exactly what I needed. Dale -- Dale D. Lutes Flight Data Systems Cessna Aircraft Company 316-517-7109