Archive-Date: Sat, 1 Jan 2000 00:54:26 -0400 Date: Fri, 31 Dec 1999 23:45:44 -0600 (CST) From: TECH@CJIS.CI.LINCOLN.NE.US Reply-To: Info-TCPware@process.com Subject: RE: Purveyor Y2K bug In-Reply-To: "Your message dated Fri, 31 Dec 1999 19:32:17 -0400" <009E374E.35ECB1F1.13@process.com> To: Info-TCPware@process.com Message-ID: <01JK64JL1NJ4006SPP@CJIS.CI.LINCOLN.NE.US> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII In August I checked with Process software and was assured that our release of Purveyor was Y2K compliant so I wasnt watching the mail as closely as I should. We are one of the few sites still on maintenance till March, 2000 Guess we lucked out? Seems strange to password the download when its licensed and the product is terminated. Thanks for the response tho. >TECH@CJIS.CI.LINCOLN.NE.US writes: >> >>It would be great if those instructions were posted here for any of us >>in a similar situation! How about it? >> > I unfortunately don't have the instructions. However, they are available > from your support rep. Also, we sent out a large number of upgrade kits > to Purveyor customers around thanksgiving. If you have that distribution, > you can find the instructions in there. > Unfortunately I know nothing of the decision to have the password protected > FTP download, so I can't comment on why that is [and thus, why the > information can't be posted publicly]. > -Jeff >-- >Jeff Schreiber, Process Software Corp. >schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 3 Jan 2000 08:58:46 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE860229E8FD@lespaul.process.com> From: Garry Frizzell Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: PSC case # 74593 - TCPware 5.4 - DHCP server died Date: Mon, 3 Jan 2000 08:55:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Curtis from Western Kentucky sends the following: Found my DHCP server had died and saw the following in operator.log: %%%%%%%%%%% OPCOM 1-JAN-2000 18:15:11.52 %%%%%%%%%%% Message from user WILLIAMSCA on AXP1 PSCDHCPD-E-Abandoning IP address 161.6.71.27: pinged before offer %%%%%%%%%%% OPCOM 1-JAN-2000 18:15:12.54 %%%%%%%%%%% Message from user WILLIAMSCA on AXP1 PSCDHCPD-E-dhcp_reply was supplied lease with no state! %%%%%%%%%%% OPCOM 1-JAN-2000 18:15:12.54 %%%%%%%%%%% Message from user WILLIAMSCA on AXP1 PSCDHCPD-F-exiting. %%%%%%%%%%% OPCOM 1-JAN-2000 18:15:12.74 %%%%%%%%%%% Message from user WILLIAMSCA on AXP1 TCPware_DHCPD, DHCPD Exited 1 What happened here? Why did the DHCP server die? Thanks in advance for any help. Garry J Frizzell Technical Support Representative Process Software Corp 959 Concord St. Framingham MA 01701-4682 " http://www.process.com * mailto:frizzell@process.com * 800-722-7770 x319 ================================================================================ Archive-Date: Tue, 4 Jan 2000 14:42:18 -0400 Date: Tue, 4 Jan 2000 13:39:24 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <009E3A41.936770ED.1@goat.process.com> Subject: RE: TCPWAre 5.4-3 SMTP Server customization routines "Ruslan R. Laishev" writes: > > Under 5.4 exist ability to some customization of the SMTP symbiont, is >there some "customization routines" for SMTP Server? I'm would like to >performs some additional checking of "relay allow/disallow" for remote >addreses with my own discipline. > The USER_SMTP_DISPATCH.C file is used by both the SMTP server and the SMTP symbiont, but currently only the vrfy_lookup and expn_lookup routines are called by the server. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 4 Jan 2000 16:37:17 -0400 Message-ID: <387262C9.BE791FAF@SMTP.DeltaTel.RU> Date: Wed, 05 Jan 2000 00:14:49 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWAre 5.4-3 SMTP Server customization routines Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hunter Goatley wrote: > > "Ruslan R. Laishev" writes: > > > > Under 5.4 exist ability to some customization of the SMTP symbiont, is > >there some "customization routines" for SMTP Server? I'm would like to > >performs some additional checking of "relay allow/disallow" for remote > >addreses with my own discipline. > > > The USER_SMTP_DISPATCH.C file is used by both the SMTP server and the > SMTP symbiont, but currently only the vrfy_lookup and expn_lookup > routines are called by the server. Have you got any plan to expand this list by another call-outs ? > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www2.wku.edu/hunter/ -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +.....................Kick ass VMS solution!.........................+ ================================================================================ Archive-Date: Wed, 5 Jan 2000 07:55:48 -0400 Message-ID: <38733A3D.C3B5DD58@flextech.co.uk> From: Nick Lewis Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Anyone know about.... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 05 Jan 2000 12:34:05 +0000 To: Info-TCPware@PROCESS.COM Anyone know about using the Compaq Management Agents when you are running TCPWARE ? The installation instructions only discuss the use o UCX or TCP/IP Services. The main problem is that the replacement file is called ESNMP.EXE - which is not found under TCPWARE. Any assistance would be appreciated, Nick Lewis ================================================================================ Archive-Date: Wed, 5 Jan 2000 12:25:12 -0400 Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A685FF@ntprdex4.admin.liffe.com> From: Andy Williams Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: TCPware performance measurement Date: Wed, 5 Jan 2000 17:22:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Well, I'm likely to open a whole can of worms here, but in for a penny, in for a pound: Environment: OpenVMS Alpha V6.2-1H3 and TCPware V5.3-2 There's a "perception" from one of our development groups that their application is being constrained by TCPware, and I've been tasked to take an in-depth look. Now, it's very early days right now and currently I'm not even too sure what the application really gets up to until I've met some of the developers other than it reads IP-based feeds coming in, manipulates & munges something, logs the result to disk & passes it out in another IP-based feed. Before anyone asks I've not got detailed performance stats (I've only just put DECps on this box today) but I thought I'd just try to find out if anybody has any pointers on what to look for (or at) within TCPware to acquire some basic figures. I know the DECps package won't measure any IP-based stuff directly but it's there to give an overall picture of the system. Cheers, Andy Williams OpenVMS System Specialist Andy.Williams@LIFFE.nospam.com +44 171 379 2581 ---------------------------------------------------------------------- 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: Wed, 5 Jan 2000 12:29:48 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: MIME attachments Date: Wed, 5 Jan 2000 17:25:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi there, I want to email attachments from my VMS systems to internet users using MIME. How can I do this with TCPware and OpenVMS ? Do I need VMS 7.2 and TCPware 5.4 ? What would the procedure be (ie do I create a MIME attachement and then just use mail/foreign) ? Thanks, Derek... *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This e-mail is intended only for the individual or entity to which it is addressed and contains information that is private and confidential. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error please delete it immediately and advise us by return e-mail to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Wed, 5 Jan 2000 13:32:54 -0400 Message-ID: <8520E1AE8EDBD211995200A0C9E98AD7011A0E09@chelsea.vfl.vodafone> From: Alex.Daniels@vf.vodafone.co.uk Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: RE: TCPware performance measurement Date: Wed, 5 Jan 2000 18:29:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Andy, Dont really know what you are after, but this may help you get some basic info, below is from one of my AlphaServer 8400's, again running 6.2-1H3, but TCPware 5.3-4. System uptime is 31 days. NETCU> show coun TCPware(R) for OpenVMS Counters: Seconds since zeroed: 2759912 TCP segments transmitted: 30065134 TCP segments received: 38274259 Delayed ACKs: 2261421 Out of sequence: 110 Window updates: 318 Receive errors: 0 Segments retransmitted: 9301043 Concatenated RDBs: 0 Keep-alives/Persists: 9276486 Transmit errors: 0 Concatenated XDBs: 22952155 Seconds since zeroed: 2759912 UDP datagrams transmitted: 224879993 UDP datagrams received: 258974544 Transmit errors: 0 Receive errors: 1 Undelivered datagrams: 34223114 Also.... NETCU> show ser TCPware(R) for OpenVMS NETCP Services: Protocol Port Active Limit Connects Errors Image -------- ---- ------ ----- -------- ------ ----- STREAM telnet 0 none 7865 0 STREAM time 0 none 0 0 STREAM auth 0 none 1 0 DGRAM time 0 1 0 0 TCP echo 0 none 0 0 TCPWARE:ECHOD TCP discard 0 none 0 0 TCPWARE:DISCARDD TCP daytime 0 none 0 0 TCPWARE:DAYTIMED TCP quote 0 none 0 0 TCPWARE:QUOTED TCP chargen 0 none 0 0 TCPWARE:CHARGEND TCP ftp 0 none 4 0 SYS$SYSTEM:LOGINOUT TCP vss2 44 200 13938 0 SYS$SYSTEM:LOGINOUT.EXE TCP vss2_md 0 24 75320 69861 SYS$SYSTEM:LOGINOUT.EXE ..... ...here I have a number of errors on a port I disabled for a while. NETCU> show conn/con ... This will show you send and recieve queue counts live, per active connection. Alex Daniels OpenVMS System manager Vodafone Airtouch PLC -----Original Message----- From: Andy Williams [mailto:Andy.Williams@liffe.com] Sent: Wednesday, January 05, 2000 5:22 PM To: 'info-tcpware@process.com' Subject: TCPware performance measurement Well, I'm likely to open a whole can of worms here, but in for a penny, in for a pound: Environment: OpenVMS Alpha V6.2-1H3 and TCPware V5.3-2 There's a "perception" from one of our development groups that their application is being constrained by TCPware, and I've been tasked to take an in-depth look. Now, it's very early days right now and currently I'm not even too sure what the application really gets up to until I've met some of the developers other than it reads IP-based feeds coming in, manipulates & munges something, logs the result to disk & passes it out in another IP-based feed. Before anyone asks I've not got detailed performance stats (I've only just put DECps on this box today) but I thought I'd just try to find out if anybody has any pointers on what to look for (or at) within TCPware to acquire some basic figures. I know the DECps package won't measure any IP-based stuff directly but it's there to give an overall picture of the system. Cheers, Andy Williams OpenVMS System Specialist Andy.Williams@LIFFE.nospam.com +44 171 379 2581 ---------------------------------------------------------------------- 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: Wed, 5 Jan 2000 13:35:43 -0400 Date: Wed, 5 Jan 2000 12:32:46 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000105123246.202000c1@process.com> Subject: RE: MIME attachments Derek Fage writes: > >Hi there, > >I want to email attachments from my VMS systems to internet users using >MIME. > >How can I do this with TCPware and OpenVMS ? Do I need VMS 7.2 and TCPware >5.4 ? > >What would the procedure be (ie do I create a MIME attachement and then just >use mail/foreign) ? > With TCPware V5.4, you can just use VMS Mail to send it: MAIL> send/noedit/foreign file.ext !Send a special VMS-only MIME msg MAIL> send/noedit/foreign/type=1 file.ext !Send a generic MIME msg Those aren't really attachments, but the second command can be used to send files as base64-encoded MIME messages to any client. I've never played with the MIME utility in V7.2; I need to do that. Right now, there's not an easy way to mail a MIME-produced file via TCPware's SMTP. I'll try to work up a way to do so. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 5 Jan 2000 15:15:38 -0400 Date: Wed, 5 Jan 2000 15:13:21 GMT From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com To: INFO-TCPWARE@PROCESS.COM Message-ID: <000105151321.17df5@ENDOR.COM> Subject: telnet permanent device When you use the telnet /create=(perm)/logical=devv1 199.204.22.64 6007 the logical is a process logical. Is there a way to make is a system logical if you have the privs, during the telnet/create command. I would hate to have to write a dcl command procedure to make the logical system wide. john babiarz ================================================================================ Archive-Date: Wed, 5 Jan 2000 15:23:34 -0400 Sender: DLUTES@fw1.textron.com Message-ID: <3873532D.534E1A3D@cessna.textron.com> Date: Wed, 05 Jan 2000 14:20:29 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: MIME attachments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Derek Fage wrote: > I want to email attachments from my VMS systems to internet users using > MIME. > > How can I do this with TCPware and OpenVMS ? Do I need VMS 7.2 and TCPware > 5.4 ? One solution is to use Netscape for VMS and let it handle the MIME encoding and attachments for you. It's how I do all of my internet e-mail. -- Dale D. Lutes Flight Data Systems Cessna Aircraft Company 316-517-7109 ================================================================================ Archive-Date: Wed, 5 Jan 2000 15:31:44 -0400 Sender: schreiber@process.com Date: Wed, 5 Jan 2000 15:28:50 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E3B1A.079C9625.201@process.com> Subject: RE: telnet permanent device babiarz@ENDOR.COM writes: > > >When you use the telnet /create=(perm)/logical=devv1 199.204.22.64 6007 > >the logical is a process logical. Is there a way to make is a system logical >if you have the privs, during the telnet/create command. I would hate to >have to write a dcl command procedure to make the logical system wide. > [/TABLE=table] takes either PROCESS (default) JOB, GROUP, or SYSTEM [/MODE=mode] takes SUPERVISOR (default) or EXECUTIVE so: telnet /create=(perm)/logical=devv1/table=sys/mode=exec 199.204.22.64 6007 Gives you a system exec logical. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 5 Jan 2000 15:39:22 -0400 Date: Wed, 5 Jan 2000 15:35:13 GMT From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000105153513.17df5@ENDOR.COM> Subject: RE: telnet permanent device >> >> >>When you use the telnet /create=(perm)/logical=devv1 199.204.22.64 6007 >> >>the logical is a process logical. Is there a way to make is a system logical >>if you have the privs, during the telnet/create command. I would hate to >>have to write a dcl command procedure to make the logical system wide. >> > > [/TABLE=table] takes either PROCESS (default) JOB, GROUP, or SYSTEM > [/MODE=mode] takes SUPERVISOR (default) or EXECUTIVE > > so: > > telnet /create=(perm)/logical=devv1/table=sys/mode=exec 199.204.22.64 6007 > > Gives you a system exec logical. >-- >Jeff Schreiber, Process Software Corp. >schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever Thanks for another undocumented command. I will put it to good use john ================================================================================ Archive-Date: Wed, 5 Jan 2000 15:46:00 -0400 Sender: schreiber@process.com Date: Wed, 5 Jan 2000 15:43:05 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E3B1C.059D9DF9.36@process.com> Subject: RE: telnet permanent device babiarz@ENDOR.COM writes: > >Thanks for another undocumented command. I will put it to good use > Perhaps it should be documented on a separate line, but look at the /LOGICAL documentation on the USERS Guide, page 12-33 (in the 5.4 docs) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 5 Jan 2000 15:54:31 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8601E75419@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Anyone know about.... Date: Wed, 5 Jan 2000 15:51:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" TCPware currently does not support the Compaq Management Agents. We are working on supporting them in a future version. -----Original Message----- From: Nick Lewis [mailto:nick_lewis@flextech.co.uk] Sent: Wednesday, January 05, 2000 7:34 AM To: Info-TCPware@PROCESS.COM Subject: Anyone know about.... Anyone know about using the Compaq Management Agents when you are running TCPWARE ? The installation instructions only discuss the use o UCX or TCP/IP Services. The main problem is that the replacement file is called ESNMP.EXE - which is not found under TCPWARE. Any assistance would be appreciated, Nick Lewis ================================================================================ Archive-Date: Wed, 5 Jan 2000 16:47:45 -0400 Sender: goatley@triton.process.com Return-Path: Date: Wed, 5 Jan 2000 15:52:18 GMT From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000105155218.17df5@ENDOR.COM> Subject: RE: telnet permanent device > > Perhaps it should be documented on a separate line, but look at the > /LOGICAL documentation on the USERS Guide, page 12-33 (in the 5.4 > docs) Yes you are right, but I think where the example was given on PG 12-10 concerning the discussion of permanent NTA devices would be helpfull also john ================================================================================ Archive-Date: Wed, 5 Jan 2000 17:41:48 -0400 From: "David Prosser" Reply-To: Info-TCPware@process.com Subject: TCP causing Session dropouts Message-ID: Date: Thu, 6 Jan 2000 09:21:07 +1100 To: Info-TCPware@PROCESS.COM I initially thought this was a Unix problem, but the same thing is happening under VMS. I'm running several portable RF terminals connected to a host machine via TCP/IP. These terminals have a power-down to save battery life after 1-60 mins. Less than 5 minutes after power-down, the session is disconnected by the Host since (I am told) a keepalive signal has not been responded to. Can this keepalive timeout period be extended (or disabled?). Where does this get set under VMS? Grateful for any advice. dprosser@pulseming.com.au ================================================================================ Archive-Date: Wed, 5 Jan 2000 17:49:22 -0400 From: "W. Marlin Johnson (BHAM) " Reply-To: Info-TCPware@process.com To: Subject: RE: telnet permanent device Date: Wed, 5 Jan 2000 16:49:14 -0600 Message-ID: <003901bf57cf$1795c000$9cac100c@wm_johnson.commanddata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <000105155218.17df5@ENDOR.COM> Speaking of permanent telnet ports... I was looking into a similar matter a short time ago. What I gathered from the manuals and online materials is that a permanent telnet port (or device) could be created but only as an outbound device from the VMS host (or perhaps "telnet session originating" device would say it better). However, what I was trying to find was a way to create a virtual port type device (a la TWA or FTA) as a "telnet session answering" device which could then be owned by a detached process (essentially a menuing program which lets our customers access various parts of our applications). The advantage to this is that it would let our customers migrate from their current serial or proprietary protocol (non-routable) ethernet connections to more standard tcp/ip connections without having to purchase beau coupe VMS user licenses. So, I was hoping you wise and learned folks could provide some pointers toward how to make this possible (or else be able to say authoritatively "Give it up!"). Thanks in advance! Marlin Johnson mjohnson@commanddata.com --I am just an egg-- -----Original Message----- From: goatley@triton.process.com [mailto:goatley@triton.process.com]On Behalf Of babiarz@ENDOR.COM Sent: Wednesday, January 05, 2000 9:52 AM To: Info-TCPware@process.com Subject: RE: telnet permanent device > > Perhaps it should be documented on a separate line, but look at the > /LOGICAL documentation on the USERS Guide, page 12-33 (in the 5.4 > docs) Yes you are right, but I think where the example was given on PG 12-10 concerning the discussion of permanent NTA devices would be helpfull also john ================================================================================ Archive-Date: Wed, 5 Jan 2000 19:16:10 -0400 Message-ID: <3873DDA1.D74F0081@home.com> From: Dave Grubb Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: NFS Client "V3" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 06 Jan 2000 00:11:14 GMT To: Info-TCPware@PROCESS.COM Hi - Anybody out there know if TCPWare 5.4-3 supports NFS Client V3 ? Where is V3 defined: '73 Dave Grubb ================================================================================ Archive-Date: Wed, 5 Jan 2000 23:26:28 -0400 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: MIME attachments Message-ID: <3873a84d.524144494f47414741@radiogaga.harz.de> Date: Wed, 05 Jan 2000 21:23:41 +0100 Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Derek Fage (DerekF@ITEXJSY.com) wrote: : I want to email attachments from my VMS systems to internet users using : MIME. : : How can I do this with TCPware and OpenVMS ? Do I need VMS 7.2 and TCPware : 5.4 ? : : What would the procedure be (ie do I create a MIME attachement and then just : use mail/foreign) ? AFAIK, TCPware doen't come with MIME support. What you need is a Mail User Agent (MUA, i.e. a mailreader) that can cope with attachments. The only one for VMS I know of is PINE, probably on the Freeware CD, or from http://alder.cc.kcl.ac.uk/fileserv/pine-vms/. You can buy a supported version with PMDF. 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: Thu, 6 Jan 2000 04:18:20 -0400 Message-ID: <001a01bf5826$3f99aa60$0e0d10ac@CN02638.nbbs.nl> From: "Johan Parlevliet" Reply-To: Info-TCPware@process.com To: Subject: Re: MIME attachments Date: Thu, 6 Jan 2000 10:13:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I use uuencode from UUCODE from MADGOAT http://www.wku.edu/www/fileserv/fileserv.html to get attachments in a mail I sent a textfile to internet users. This textfile needed an extra line so i did that with GAWK (also from madgoat) $! Add extra at end of line $ Gawk upload_file /commands="{print $0 """"}" /output=tmpfile.txt $! The in previous line is a real carriage return character, \n did not work here $ Mcr nbbs:uuencode.exe tmpfile.txt /name=DOCUMEN.TXT /output=tmpfile2.txt $ mail tmpfile2.txt "xxx@yyy.nl" /subject="subject" -----Original Message----- From: Derek Fage To: Info-TCPware@process.com Date: woensdag, 05 januari 2000 18:28 Subject: MIME attachments >Hi there, > >I want to email attachments from my VMS systems to internet users using >MIME. > >How can I do this with TCPware and OpenVMS ? Do I need VMS 7.2 and TCPware >5.4 ? > >What would the procedure be (ie do I create a MIME attachement and then just >use mail/foreign) ? > >Thanks, > >Derek... > > > >*********************************************************************** >Any views expressed in this message are those of the individual sender, >except where the sender states them to be the views of Itex Limited. > >This e-mail is intended only for the individual or entity to which it is >addressed and contains information that is private and confidential. If >you are not the intended recipient you are hereby notified that any >dissemination, distribution or copying is strictly prohibited. If you >have received this e-mail in error please delete it immediately and >advise us by return e-mail to administrator@itexjsy.com. > >*********************************************************************** > ================================================================================ Archive-Date: Thu, 6 Jan 2000 05:23:05 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E05BB@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: INFO-TCPWARE@PROCESS.COM Subject: NTP errors Date: Thu, 6 Jan 2000 11:18:00 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF582F.511C0A35" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF582F.511C0A35 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I am using a VMS system alpha 7.1-2 with tcpware 5.3-2 (netcp patch = 1.0) I have errors some days, and some days it works (with the same configuration!) : SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;330 28 Aug 07:39:00 can't sync battery time. SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;331 29 Aug 12:11:38 NTPD started 29 Aug 12:11:39 acquired peer LOCAL(1) 29 Aug 12:15:56 selected new sync source LOCAL(1), now at stratum 9 Here is my configuration. The server is a DECnet/OSI dtss clock master. SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTP.conf master-clock 8 Presently, I still have the same errors... Notice that the ntp synchronization seems to work fine. Any ideas,=20 Regards, Pierre Clairembault ----------------------------- Banque CPR Architecture/r=E9seau mailto:pclairembault@cpr.fr ------_=_NextPart_001_01BF582F.511C0A35 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NTP errors

Hello,

I am using a VMS system alpha 7.1-2 = with tcpware 5.3-2 (netcp patch 1.0)

I have errors some days, and some days = it works (with the same configuration!) :

SYS_SAMBA> ty = SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;330
28 Aug 07:39:00 can't sync battery = time.

SYS_SAMBA> ty = SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;331
29 Aug 12:11:38 NTPD started
29 Aug 12:11:39 acquired peer = LOCAL(1)
29 Aug 12:15:56 selected new sync = source LOCAL(1), now at stratum 9

Here is my configuration. The server = is a DECnet/OSI dtss clock master.

SYS_SAMBA> ty = SYS$SPECIFIC:[TCPWARE]NTP.conf
master-clock 8

Presently, I still have the same = errors...

Notice that the ntp synchronization = seems to work fine.

Any ideas,

Regards,

Pierre Clairembault
-----------------------------
Banque CPR
Architecture/r=E9seau
mailto:pclairembault@cpr.fr

------_=_NextPart_001_01BF582F.511C0A35-- ================================================================================ Archive-Date: Thu, 6 Jan 2000 07:38:35 -0400 Message-ID: <38747FD5.D43525F9@SMTP.DeltaTel.RU> Date: Thu, 06 Jan 2000 14:43:17 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: NTP errors Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit To: Info-TCPware@PROCESS.COM NTP can't set time if DTSS run on the same host. Stop DTSS or use DTSS$NTP_provider (see in sys$examples). > CLAIREMBAULT Pierre wrote: > > Hello, > > I am using a VMS system alpha 7.1-2 with tcpware 5.3-2 (netcp patch 1.0) > > I have errors some days, and some days it works (with the same configuration!) : > > SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;330 > 28 Aug 07:39:00 can't sync battery time. > > SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;331 > 29 Aug 12:11:38 NTPD started > 29 Aug 12:11:39 acquired peer LOCAL(1) > 29 Aug 12:15:56 selected new sync source LOCAL(1), now at stratum 9 > > Here is my configuration. The server is a DECnet/OSI dtss clock master. > > SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTP.conf > master-clock 8 > > Presently, I still have the same errors... > > Notice that the ntp synchronization seems to work fine. > > Any ideas, > > Regards, > > Pierre Clairembault > ----------------------------- > Banque CPR > Architecture/rĘseau > mailto:pclairembault@cpr.fr -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Thu, 6 Jan 2000 08:24:04 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E05BC@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NTP errors Date: Thu, 6 Jan 2000 14:20:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5848.D1953678" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5848.D1953678 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable In fact, my ntp peers are UNIX and NT servers, not DTSS hosts. So it is = not a problem. I have seen on the DECdts documentation that whe can have both (ntpd = and dtss) on the same host with ntp.conf (master-clock 8). I have this configuration for years and the error message appears now. Pierre -----Message d'origine----- De: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU] Date: jeudi 6 janvier 2000 12:43 =E1: Info-TCPware@PROCESS.COM Objet: Re: NTP errors NTP can't set time if DTSS run on the same host. Stop DTSS or use DTSS$NTP_provider (see in sys$examples). > CLAIREMBAULT Pierre wrote: >=20 > Hello, >=20 > I am using a VMS system alpha 7.1-2 with tcpware 5.3-2 (netcp patch = 1.0) >=20 > I have errors some days, and some days it works (with the same configuration!) : >=20 > SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;330 > 28 Aug 07:39:00 can't sync battery time. >=20 > SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;331 > 29 Aug 12:11:38 NTPD started > 29 Aug 12:11:39 acquired peer LOCAL(1) > 29 Aug 12:15:56 selected new sync source LOCAL(1), now at stratum 9 >=20 > Here is my configuration. The server is a DECnet/OSI dtss clock = master. >=20 > SYS_SAMBA> ty SYS$SPECIFIC:[TCPWARE]NTP.conf > master-clock 8 >=20 > Presently, I still have the same errors... >=20 > Notice that the ntp synchronization seems to work fine. >=20 > Any ideas, >=20 > Regards, >=20 > Pierre Clairembault > ----------------------------- > Banque CPR > Architecture/r=CAseau > mailto:pclairembault@cpr.fr --=20 Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ------_=_NextPart_001_01BF5848.D1953678 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable RE: NTP errors

In fact, my ntp peers are UNIX and NT servers, not = DTSS hosts. So it is not a problem.
I have seen on the DECdts documentation that whe can = have both (ntpd and dtss) on the same host with ntp.conf (master-clock = 8).

I have this configuration for years and the error = message appears now.

Pierre

-----Message d'origine-----
De: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU= ]
Date: jeudi 6 janvier 2000 12:43
=E1: Info-TCPware@PROCESS.COM
Objet: Re: NTP errors


NTP can't set time if DTSS run on the same host. Stop = DTSS or use DTSS$NTP_provider
(see in sys$examples).


> CLAIREMBAULT Pierre wrote:
>
> Hello,
>
> I am using a VMS system alpha 7.1-2 with = tcpware 5.3-2 (netcp patch 1.0)
>
> I have errors some days, and some days it works = (with the same configuration!) :
>
> SYS_SAMBA> ty = SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;330
> 28 Aug 07:39:00 can't sync battery time.
>
> SYS_SAMBA> ty = SYS$SPECIFIC:[TCPWARE]NTPSERVER.LOG;331
> 29 Aug 12:11:38 NTPD started
> 29 Aug 12:11:39 acquired peer LOCAL(1)
> 29 Aug 12:15:56 selected new sync source = LOCAL(1), now at stratum 9
>
> Here is my configuration. The server is a = DECnet/OSI dtss clock master.
>
> SYS_SAMBA> ty = SYS$SPECIFIC:[TCPWARE]NTP.conf
> master-clock 8
>
> Presently, I still have the same = errors...
>
> Notice that the ntp synchronization seems to = work fine.
>
> Any ideas,
>
> Regards,
>
> Pierre Clairembault
> -----------------------------
> Banque CPR
> Architecture/r=CAseau
> mailto:pclairembault@cpr.fr

--
Cheers,
+OpenVMS [Sys|Net] = HardWorker........................................+
 Russia,Delta Telecom = JSC,           &n= bsp;        Cel:  +7 (901) = 971-3222
 191119,St.Petersburg,Transportny per. = 3            = ;         116-3222
          &nb= sp;           &nb= sp;           &nb= sp;           = Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... = SysMan rides HailStorm +

------_=_NextPart_001_01BF5848.D1953678-- ================================================================================ Archive-Date: Thu, 6 Jan 2000 08:32:12 -0400 Sender: schreiber@process.com Date: Thu, 6 Jan 2000 08:29:15 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E3BA8.94DAC71C.91@process.com> Subject: RE: NFS Client "V3" Dave Grubb writes: > >Anybody out there know if TCPWare 5.4-3 supports >NFS Client V3 ? Where is V3 defined: > Not 5.4-3, but we are researching the protocol. V3 is defined in RFC 1813. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 6 Jan 2000 08:32:41 -0400 From: Sylvain Plante Reply-To: Info-TCPware@process.com Subject: NFS problems Date: Thu, 06 Jan 2000 08:24:08 -0500 Message-ID: <38749778.BD557E63@toto.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi everybody, Configuration: OpenVMS 6.2-1H3 and TCPware 5.3-2 We are using NFS client from our OpenVMS server to reach a Sun Solaris 2.6 server. Here's the command to mount it: $ nfsmount/system/cache=(dir=00:00:01,ATT=00:00:01,READ)/trans=tcp/processor=unique unixnode "/export/ftp" -nfs5: ftpsite Since the new year the NFS node is freezing once in a while. If I try to reach the unix server my session is freezing and the only way to correct it is to reboot my OpenVMS server. Here's the OPCOM message: %%%% OPCOM 5-jan-2000 09:06:4392 %%%%%%%%%% (from node LAMERA at 5-jan-2000 09:01) Message from user SYSTEM on LAMERA Client NFS ACP (20C0022D) - NFS server on host unixnode.cff.park.ca is not responding %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I can stop the NFS client on LAMERA (@tcpware:shutnet nfs), but as soon as I try to dismount nfs5:, I freeze. I cannot stop the process ID 20C0022D because it is an object. At the same time on another OpenVMS server, I can reach easily the data. Help please Sylvain Plante splante@rncan.gc.ca ================================================================================ Archive-Date: Fri, 7 Jan 2000 07:10:27 -0400 From: Adrian.Parker@rb.cwplc.com Reply-To: Info-TCPware@process.com Subject: NDR Date: Fri, 07 Jan 2000 11:47:21 GMT Message-ID: <854jo7$hk0$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM When I receive a NDR in Outlook from TCPware, the origianl message is sent back as an attachment. I'm trying to use the link monitor utility in Exchange Administrator and it only seems to be able to check message subject or body. Is there a way of making TCPware send the NDR in the body rather than as an attachment? Cheers, Adrian Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Fri, 7 Jan 2000 08:12:24 -0400 Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A6861A@ntprdex4.admin.liffe.com> From: Andy Williams Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" CC: "'Alex.Daniels@vf.vodafone.co.uk'" Subject: RE: TCPware performance measurement Date: Fri, 7 Jan 2000 13:09:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks for the pointers. I was more interested in exactly what these counters mean - over & above the one-line description in the programmer's guide. For example, what are the potential implications of out-of-sequence segments, or should I read anything into low counter values for concatenated buffers. It's difficult to gain an understanding of the relevance of these counters without understanding what TCPware's doing under the surface - and that information doesn't seem to be available. The NETCU SHO CONN command talks about send & receive queues but gives no pointers on whether values in these fields on a more-or-less permanent basis could be alleviated by increasing various SYSGEN parameters or process quotas somewhere. How many bytes can be held in the queue before something breaks ? With high values is there a knock-on effect that causes nonpaged pool to be eaten ? If our system developers come to me & say that they're planning on doubling the amount of IP connections on the system I have no idea whether I should be increasing any kind of quotas/values within TCPware or whether it simply "handles it". From the VMS side I know that each IP-type link will require a channel so I may need to look at FILLM or CHANNELCNT but the manuals give no hints that I can find. In comparison, I can watch DECnet phase IV counters fairly carefully. I know the implications of the maximum links or maximum objects and I know when the system starts to approach these limits. Are there any 'hints-n-kinks' type documents for TCPware or does it truly not need to be adjusted for increasing workloads. Cheers, Andy -----Original Message----- From: Alex.Daniels@vf.vodafone.co.uk [mailto:Alex.Daniels@vf.vodafone.co.uk] Sent: Wednesday, January 05, 2000 6:30 PM To: Info-TCPware@process.com Subject: RE: TCPware performance measurement ---------------------------------------------------------------------- Warning - This email originates from the Internet. If you are in any doubt as to the contents of the email then contact PC Support on ext.2288. ---------------------------------------------------------------------- Andy, Dont really know what you are after, but this may help you get some basic info, below is from one of my AlphaServer 8400's, again running 6.2-1H3, but TCPware 5.3-4. System uptime is 31 days. NETCU> show coun TCPware(R) for OpenVMS Counters: Seconds since zeroed: 2759912 TCP segments transmitted: 30065134 TCP segments received: 38274259 Delayed ACKs: 2261421 Out of sequence: 110 Window updates: 318 Receive errors: 0 Segments retransmitted: 9301043 Concatenated RDBs: 0 Keep-alives/Persists: 9276486 Transmit errors: 0 Concatenated XDBs: 22952155 Seconds since zeroed: 2759912 UDP datagrams transmitted: 224879993 UDP datagrams received: 258974544 Transmit errors: 0 Receive errors: 1 Undelivered datagrams: 34223114 Also.... NETCU> show ser TCPware(R) for OpenVMS NETCP Services: Protocol Port Active Limit Connects Errors Image -------- ---- ------ ----- -------- ------ ----- STREAM telnet 0 none 7865 0 STREAM time 0 none 0 0 STREAM auth 0 none 1 0 DGRAM time 0 1 0 0 TCP echo 0 none 0 0 TCPWARE:ECHOD TCP discard 0 none 0 0 TCPWARE:DISCARDD TCP daytime 0 none 0 0 TCPWARE:DAYTIMED TCP quote 0 none 0 0 TCPWARE:QUOTED TCP chargen 0 none 0 0 TCPWARE:CHARGEND TCP ftp 0 none 4 0 SYS$SYSTEM:LOGINOUT TCP vss2 44 200 13938 0 SYS$SYSTEM:LOGINOUT.EXE TCP vss2_md 0 24 75320 69861 SYS$SYSTEM:LOGINOUT.EXE ..... ...here I have a number of errors on a port I disabled for a while. NETCU> show conn/con ... This will show you send and recieve queue counts live, per active connection. Alex Daniels OpenVMS System manager Vodafone Airtouch PLC -----Original Message----- From: Andy Williams [mailto:Andy.Williams@liffe.com] Sent: Wednesday, January 05, 2000 5:22 PM To: 'info-tcpware@process.com' Subject: TCPware performance measurement Well, I'm likely to open a whole can of worms here, but in for a penny, in for a pound: Environment: OpenVMS Alpha V6.2-1H3 and TCPware V5.3-2 There's a "perception" from one of our development groups that their application is being constrained by TCPware, and I've been tasked to take an in-depth look. Now, it's very early days right now and currently I'm not even too sure what the application really gets up to until I've met some of the developers other than it reads IP-based feeds coming in, manipulates & munges something, logs the result to disk & passes it out in another IP-based feed. Before anyone asks I've not got detailed performance stats (I've only just put DECps on this box today) but I thought I'd just try to find out if anybody has any pointers on what to look for (or at) within TCPware to acquire some basic figures. I know the DECps package won't measure any IP-based stuff directly but it's there to give an overall picture of the system. Cheers, Andy Williams OpenVMS System Specialist Andy.Williams@LIFFE.nospam.com +44 171 379 2581 ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- ---------------------------------------------------------------------- The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies. ---------------------------------------------------------------------- ================================================================================ Archive-Date: Fri, 7 Jan 2000 08:12:45 -0400 Date: Fri, 7 Jan 2000 7:09:50 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000107070950.202000c1@process.com> Subject: RE: NDR Adrian.Parker@rb.cwplc.com writes: > >When I receive a NDR in Outlook from TCPware, the origianl message is >sent back as an attachment. I'm trying to use the link monitor utility >in Exchange Administrator and it only seems to be able to check message >subject or body. Is there a way of making TCPware send the NDR in the >body rather than as an attachment? > Maybe I'm running on too little sleep, but what's an NDR? In any case, TCPware prior to V5.4 isn't capable of sending anything as an attachment, and in V5.4, you have to explicitly tell VMS Mail to generate such a message (using /FOREIGN/TYPE=1). My guess is that whatever is generating the NDR is creating it as a MIME message. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 7 Jan 2000 14:23:29 -0400 Sender: goatley@triton.process.com Return-Path: From: leslie@clio.rice.edu (Jerry Leslie) Reply-To: Info-TCPware@process.com Subject: Re: NDR Date: 7 Jan 2000 17:22:20 GMT Message-ID: <8557cc$bf5$1@joe.rice.edu> To: Info-TCPware@PROCESS.COM Hunter Goatley (goathunter@process.com) wrote: : Maybe I'm running on too little sleep, but what's an NDR? Thanks to an Altavista search: Non-Delivery Report (NDR) --Jerry Leslie (my opinions are strictly my own) ================================================================================ Archive-Date: Sat, 8 Jan 2000 15:55:35 -0400 From: leslie@clio.rice.edu (Jerry Leslie) Reply-To: Info-TCPware@process.com Subject: Re: NFS Client "V3" Date: 8 Jan 2000 20:34:06 GMT Message-ID: <8586vu$gkp$2@joe.rice.edu> To: Info-TCPware@PROCESS.COM Dave Grubb (dgrubb3@home.com) wrote: : Hi - : Anybody out there know if TCPWare 5.4-3 supports : NFS Client V3 ? I don't know. As of a year or so ago, neither TCPWare, Multinet, nor UCX supported V3. : Where is V3 defined: RFC 1813, available at: http://www.faqs.org/ Internet FAQ Consortium --Jerry Leslie (my opinions are strictly my own) ================================================================================ Archive-Date: Sat, 8 Jan 2000 16:42:01 -0400 Date: Sat, 8 Jan 2000 15:39:02 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: INFO-TCPWARE@PROCESS.COM Message-ID: <000108153902.202000c2@process.com> Subject: TCPware question I'm using TCPware v5.4. I like it. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Sat, 8 Jan 2000 16:42:59 -0400 Message-ID: <3877AEAF.91505B4@PROCESS.COM> Date: Sat, 08 Jan 2000 15:39:59 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: test with attachment Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === tcpware v5.4 did this make it through? -- Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ === MIME part removed : unknown type === ================================================================================ Archive-Date: Sat, 8 Jan 2000 16:58:04 -0400 Message-ID: <3877AC8F.14933CCD@SMTP.DeltaTel.RU> Date: Sun, 09 Jan 2000 00:30:55 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: BINDING to a speficic IP address Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! I trying to write an application wich supposed to support multihome. Is there any tips & triks to get information about of all configured for using with IP physical and pseudo interfaces? I'm would like to use some universal way wich will work under UCX/TCPWare/Multinet. TIA. -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +.....................Kick ass VMS solution!.........................+ ================================================================================ Archive-Date: Mon, 10 Jan 2000 07:40:15 -0400 From: adrian_parker@my-deja.com Reply-To: Info-TCPware@process.com Subject: Re: NDR Date: Mon, 10 Jan 2000 12:20:44 GMT Message-ID: <85ciqj$vo3$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Yes, sorry, I meant Non-Delivery Report. To make Exchange link monitor work it needs to receive a NDR from the monitored system so that it knows the system is available and can then figure out round-trip times etc. from the header, so normally you would send to a non-existent user to get back a NDR. If I send to a non- existent user to a TCPware system, the SMTP-OpenVMS mailer sends back the NDR with my original message and header as an attachment called ATTnnnnn.ATT, normally it would come back in the body of the message. I don't know if this is peculiar to our setup, but we are monitoring other types of systems okay. I've found a work-around though - Sending to an account with DISNEWMAIL sends back a NDR with the header in the message body. Cheers, Adrian Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Fri, 14 Jan 2000 23:52:58 -0400 From: David Morsberger Reply-To: Info-TCPware@process.com Subject: TCPWare and FTP Date: Fri, 14 Jan 2000 23:46:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Does anyone how to configure the FTP server to report unix style directory listing? Half of our FTP clients do not understand the VMS directory structure. I defined the following logical: "TCPWARE_FTP_UNIX_STYLE_BY_DEFAULT" = "TRUE" ================================================================================ Archive-Date: Mon, 17 Jan 2000 08:21:19 -0400 Message-ID: <3883166A.3987F0A1@baker.ie> Date: Mon, 17 Jan 2000 13:17:30 +0000 From: Darren Scully Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: Help with Tcpware Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit TCPWare Version V5. 3-2 on Alpha Server 2100 running VMS 7.2-1 Hi All, One of our customers has a problem with TCPware. They have a cluster of 5 nodes on several occasions on of the servers an alpha seems to busy to answer the cluster communication and the other nodes in the cluster close their virtual circuit to the Alpha. Has anyone seen any cases where TCPware has caused this sort of problem? Best Regards Darren Scully -- Darren Scully Baker Consultants 12 Hume Street Dublin 2 Ireland Email: Darren@Baker.ie Phone: + 353 1 6384806 Fax : + 353 1 6789070 Web : www.Baker.ie ================================================================================ Archive-Date: Mon, 17 Jan 2000 09:22:27 -0400 Date: Mon, 17 Jan 2000 09:18:41 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P021 To: TCPware-Announce@PROCESS.COM Message-ID: <01JKT128X90Y003EXS@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_V543P021 Description: Assorted FTP server fixes Release date: 17-JAN-2000 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p021.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 2.1) for TCPware version 5.4-3 14-Jan-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: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) FTP_LISTENER.EXE - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) - 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. FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) - A data corruption problem has been corrected. (DE 5298) [End of ECO announcement] ================================================================================ Archive-Date: Mon, 17 Jan 2000 09:26:50 -0400 Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A68670@ntprdex4.admin.liffe.com> From: Andy Williams Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPware ECO kit available: FTP_V543P021 Date: Mon, 17 Jan 2000 14:23:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks for the notification. Just a quick point: On the ECO database web page, TCPware V5.4 is not an option in the pull-down selection box. Any ideas when it'll be added ? Cheers, Andy Williams OpenVMS System Specialist Andy.Williams@LIFFE.nospam.com +44 171 379 2581 -----Original Message----- From: bryant@PROCESS.COM [mailto:bryant@PROCESS.COM] Sent: Monday, January 17, 2000 2:19 PM To: TCPware-Announce@PROCESS.COM Subject: TCPware ECO kit available: FTP_V543P021 ---------------------------------------------------------------------- Warning - This email originates from the Internet. If you are in any doubt as to the contents of the email then contact PC Support on ext.2288. ---------------------------------------------------------------------- TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V543P021 Description: Assorted FTP server fixes Release date: 17-JAN-2000 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p021.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 2.1) for TCPware version 5.4-3 14-Jan-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: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) FTP_LISTENER.EXE - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) - 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. FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) - A data corruption problem has been corrected. (DE 5298) [End of ECO announcement] ---------------------------------------------------------------------- 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, 17 Jan 2000 16:29:27 -0400 Message-ID: <38837E4B.930520FE@SMTP.DeltaTel.RU> Date: Mon, 17 Jan 2000 23:40:43 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 CC: "Sam G. Rozenfeld" Subject: TCPWare 5.3-3 and SECONDARY IP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! Some time ago I had had a some problem, which very puzzled me, it's related to secondary IP support implementation in the TCPWare TCP 5.3-3. We have a two member SCSI-cluster on a site, on the both node runs a number of internet applications like OSU HTTP,IUPOP3, MX and so on. For tolerance it is configured up to hundred secondary IPs (by netcu add secondary /cluster_lock). We expect that when node1 is down, node2 will accure a culster_lock and will continue to clients. The problem is if node2 have not cluster_lock at moment of startup internet applications then these application can't performs "bind" of soctes to these secondary IP. My questions: 1) Who have the problem like it ? 2) How PSC plan to resolve this problem ? -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +.....................Kick ass VMS solution!.........................+ ================================================================================ Archive-Date: Tue, 18 Jan 2000 05:14:43 -0400 Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A68673@ntprdex4.admin.liffe.com> From: Andy Williams Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: TCPware crash Date: Tue, 18 Jan 2000 10:11:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Environment: OpenVMS VAX V6.2 and TCPware V5.3-2 We had a "situation" couple of days ago where I got paged in the middle of the night to be told that TCPware "wasn't running" on one of our main production systems within a cluster. I had a look & saw that the only TCPware process running on the system was the DNS process (TCPware_DNS). A look at the NETCP.LOG file showed an entry stating "TCP shutting down" and "UDP shutting down" but had no PID in the message. A quick squint of the operator logfile showed a couple of interesting OPCOM messages: %TCPWARE_NTP-E-UNEXPCTD, select(6, ###---, 0L, 0L, &0.000000) error: invalid argument %TCPWARE_GATED-F-ALERT, Exit {filespec of GATED.EXE} [{PID}]: socket is not connected I managed to kind of reproduce this on my own system by doing a STOP/ID on the TCPware_NETCP process but of course that's by no means proof of what went on. It seems that TCPware does a fairly good job at tidying up after a problem, and coupled with the fact that the processes are fired off with the /NOACCOUNTING qualifier this means that any kind of problem investigation is difficult. Are there any other places I could look to see what happened ? Andy Williams OpenVMS System Specialist Andy.Williams@LIFFE.nospam.com +44 171 379 2581 ---------------------------------------------------------------------- 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: Tue, 18 Jan 2000 10:25:05 -0400 From: Rav Reply-To: Info-TCPware@process.com Subject: Problem with TCPWARE version 5.3-3 and WS_FTP PRO 6.2 Date: Tue, 18 Jan 2000 15:01:41 GMT Message-ID: <861v8a$8ha$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Hi, I am currently using Version 6.2 of WS_FTP PRO, and I would like to transfer the most recent modified files from one OpenVMS Vax version 7.1 directory to a PC, running Windows NT 4.0. It is impossible for me to determine when a VMS file was last modified since the WS_FTP gui only displays the VMS "Created" date of the VMS file and not the VMS "Revised" date in the DATE column on the WS_FTP window. Co-workers and I have tried changing options and logicals in WS_FTP and VMS, respectively, in order to combat the problem, but this was not successful. A senior VMS Systems Manager provided me with the following information: "I did some checking around. It appears that the date you see in FTP is whatever date the server gave the client. In other words, the client sends the command "LIST" and the server gives back the information. So this means that TCPWare is where you should be looking." Would you please tell me if any changes need to be made with FTP- OpenVMS (component of TCPWARE version 5.3-3) so that I can see the VMS "Revised" or modified date of the VMS files via the WS_FTP PRO version 6.2? NOTE: We are currently using FTP-OpenVMS from TCPWARE version 5.3-3 to provide us with file transfer services. Also, when using WS_FTP the following HOST TYPE was selected :VMS UCX Thank you for your assistance. Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Tue, 18 Jan 2000 12:00:50 -0400 Message-ID: From: "Garrido, Ramon, Mr, HQAFCEE" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPware ECO kit available: FTP_V543P021 Date: Tue, 18 Jan 2000 10:56:49 -0600 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === What is the difference between v543p020.zip and v543p021.zip ? Ramon -----Original Message----- From: bryant@process.com [mailto:bryant@process.com] Sent: Monday, January 17, 2000 8:19 AM To: TCPware-Announce@process.com Subject: TCPware ECO kit available: FTP_V543P021 TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V543P021 Description: Assorted FTP server fixes Release date: 17-JAN-2000 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p021.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 2.1) for TCPware version 5.4-3 14-Jan-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: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) FTP_LISTENER.EXE - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) - 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. FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) - A data corruption problem has been corrected. (DE 5298) [End of ECO announcement] ================================================================================ Archive-Date: Tue, 18 Jan 2000 12:07:34 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86024559CD@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPware ECO kit available: FTP_V543P021 Date: Tue, 18 Jan 2000 12:04:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" A condition was discovered where unexpected error messages could be encountered due to the new FTP_CONTROL.COM. This has been fixed in V543P021. -----Original Message----- From: Garrido, Ramon, Mr, HQAFCEE [mailto:Ramon.Garrido@hqafcee.brooks.af.mil] Sent: Tuesday, January 18, 2000 11:57 AM To: 'Info-TCPware@process.com' Subject: RE: TCPware ECO kit available: FTP_V543P021 === The original message was multipart MIME === === All non-text parts (attachments) have been removed === What is the difference between v543p020.zip and v543p021.zip ? Ramon -----Original Message----- From: bryant@process.com [mailto:bryant@process.com] Sent: Monday, January 17, 2000 8:19 AM To: TCPware-Announce@process.com Subject: TCPware ECO kit available: FTP_V543P021 TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V543P021 Description: Assorted FTP server fixes Release date: 17-JAN-2000 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p021.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 2.1) for TCPware version 5.4-3 14-Jan-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: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) FTP_LISTENER.EXE - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) - 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. FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) - A data corruption problem has been corrected. (DE 5298) [End of ECO announcement] ================================================================================ Archive-Date: Tue, 18 Jan 2000 15:44:42 -0400 From: Rav Reply-To: Info-TCPware@process.com Subject: Re: Problem with TCPWARE version 5.3-3 and WS_FTP PRO 6.2 Date: Tue, 18 Jan 2000 20:02:12 GMT Message-ID: <862grp$med$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Thanks everyone, I do not have a resolution to the problem, but I did get some closure. A Tech. Support rep from IPSWITCH, the vendor of WS_FTP PRO v.6, sent me the followinng message: "Currently, Wsftp will only show the created date. I will send this as a feature request to our wishlist." I guess this is not really a problem... In article <861v8a$8ha$1@nnrp1.deja.com>, Rav wrote: > Hi, > > I am currently using Version 6.2 of WS_FTP PRO, and I would like to > transfer the most recent modified files from one OpenVMS Vax version > 7.1 directory to a PC, running Windows NT 4.0. It is impossible for me > to determine when a VMS file was last modified since the WS_FTP gui > only displays the VMS "Created" date of the VMS file and not the VMS > "Revised" date in the DATE column on the WS_FTP window. > > Co-workers and I have tried changing options and logicals in WS_FTP and > VMS, respectively, in order to combat the problem, but this was not > successful. > > A senior VMS Systems Manager provided me with the following information: > > "I did some checking around. It appears that the date you see in FTP is > whatever date the server gave the client. In other words, the client > sends the command "LIST" and the server gives back the information. So > this means that TCPWare is where you should be looking." > > Would you please tell me if any changes need to be made with FTP- > OpenVMS (component of TCPWARE version 5.3-3) so that I can see the VMS > "Revised" or modified date of the VMS files via the WS_FTP PRO version > 6.2? > > NOTE: We are currently using FTP-OpenVMS from TCPWARE version 5.3-3 to > provide us with file transfer services. Also, when using WS_FTP the > following HOST TYPE was selected :VMS UCX > > Thank you for your assistance. > > Sent via Deja.com http://www.deja.com/ > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Tue, 18 Jan 2000 18:22:20 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602434A72@lespaul.process.com> From: Jakob Lentz Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Problem with TCPWARE version 5.3-3 and WS_FTP PRO 6.2 Date: Tue, 18 Jan 2000 18:18:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Rav, The response you got from IPSWITCH was nice, but - it's wrong. Your "senior VMS Systems Manager" was right on the money. The client receives the listing from the server and does not have a choice of which date is sent back. Currently the TCPware server behaves much like the VMS "$ dir/date" command, which shows the creation date by default. I'm not "the FTP guy" around here currently, but I believe there is some work being done regarding modification times for the next version. If this is important to you, you may wish to contact our Technical Support group and file an enhancement request, to be sure that your application is given consideration in the final implementation. Enjoy the day, its challenges and rewards, - Jake ---- Jake Lentz Process Software Corporation -----Original Message----- From: Rav [mailto:rshinh@my-deja.com] Sent: Tuesday, January 18, 2000 3:02 PM To: Info-TCPware@PROCESS.COM Subject: Re: Problem with TCPWARE version 5.3-3 and WS_FTP PRO 6.2 Thanks everyone, I do not have a resolution to the problem, but I did get some closure. A Tech. Support rep from IPSWITCH, the vendor of WS_FTP PRO v.6, sent me the followinng message: "Currently, Wsftp will only show the created date. I will send this as a feature request to our wishlist." I guess this is not really a problem... In article <861v8a$8ha$1@nnrp1.deja.com>, Rav wrote: > Hi, > > I am currently using Version 6.2 of WS_FTP PRO, and I would like to > transfer the most recent modified files from one OpenVMS Vax version > 7.1 directory to a PC, running Windows NT 4.0. It is impossible for me > to determine when a VMS file was last modified since the WS_FTP gui > only displays the VMS "Created" date of the VMS file and not the VMS > "Revised" date in the DATE column on the WS_FTP window. > > Co-workers and I have tried changing options and logicals in WS_FTP and > VMS, respectively, in order to combat the problem, but this was not > successful. > > A senior VMS Systems Manager provided me with the following information: > > "I did some checking around. It appears that the date you see in FTP is > whatever date the server gave the client. In other words, the client > sends the command "LIST" and the server gives back the information. So > this means that TCPWare is where you should be looking." > > Would you please tell me if any changes need to be made with FTP- > OpenVMS (component of TCPWARE version 5.3-3) so that I can see the VMS > "Revised" or modified date of the VMS files via the WS_FTP PRO version > 6.2? > > NOTE: We are currently using FTP-OpenVMS from TCPWARE version 5.3-3 to > provide us with file transfer services. Also, when using WS_FTP the > following HOST TYPE was selected :VMS UCX > > Thank you for your assistance. > > Sent via Deja.com http://www.deja.com/ > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Tue, 18 Jan 2000 21:28:14 -0400 From: David Morsberger Reply-To: Info-TCPware@process.com Subject: TCPWare and FTP Date: Tue, 18 Jan 2000 21:19:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Does anyone how to configure the TCPWare FTP server to report unix style directory listing? I am not sure what it does not understand about the info returned by TCPWare. Tech Support for one of the FTP client stated: >> Comments: How do I use the open via ftp feature with a VMS host? I can >> not change directories once I log in. > > You may not be able to. The FTP client will work with some VMS hosts but > with otehrs you run into the problem you are seeing. In such cases I'm > afraid it's not possible to use the ftp tool in BBEdit. We have other FTP clients that do not understand the information returned by TCPWare. I defined the following logical: "TCPWARE_FTP_UNIX_STYLE_BY_DEFAULT" = "TRUE" ================================================================================ Archive-Date: Tue, 18 Jan 2000 23:15:52 -0400 Sender: bryant@process.com Date: Tue, 18 Jan 2000 23:12:22 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009E4591.F046A47C.28@process.com> Subject: RE: TCPware ECO kit available: FTP_V543P021 Andy Williams writes: > >Thanks for the notification. Just a quick point: On the ECO database web >page, TCPware V5.4 is not an option in the pull-down selection box. Any >ideas when it'll be added ? > >Cheers, > >Andy Williams >OpenVMS System Specialist >Andy.Williams@LIFFE.nospam.com >+44 171 379 2581 Funny you should mention it. I noticed that yesterday and it has been fixed. I'm glad you apperntly find it useful. If you notice anything else, please do let us know. Thanks. ================================================================================ Archive-Date: Tue, 18 Jan 2000 23:51:38 -0400 Sender: bryant@process.com Date: Tue, 18 Jan 2000 23:48:07 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009E4596.EEFC46B2.3@process.com> Subject: RE: TCPWare 5.3-3 and SECONDARY IP "Ruslan R. Laishev" writes: > >Hi All! > Some time ago I had had a some problem, which very puzzled me, it's >related to secondary IP support implementation in the TCPWare TCP 5.3-3. > > We have a two member SCSI-cluster on a site, on the both node runs a >number of internet applications like OSU HTTP,IUPOP3, MX and so on. For >tolerance it is configured up to hundred secondary IPs (by netcu add >secondary /cluster_lock). We expect that when node1 is down, node2 will >accure a culster_lock and will continue to clients. It is correct that if node1 gfoes down, the secondary addresses it holds will fail over to node2. Your comment about "contnue to clients" depends on teh application. > The problem is if node2 have not cluster_lock at moment of startup >internet applications then these application can't performs "bind" of >soctes to these secondary IP. That is correct because the IP address does not exist on that system. It will work if the application binds to all addresses, but if it binds only to the explicit addresses it sees at startup, then there will be a problem. > My questions: > 1) Who have the problem like it ? > 2) How PSC plan to resolve this problem ? This is not something that PSC can resolve. It is a problem for the application to be able to handle a new address on the system. As I said, applications which bind to INADDR_ANY (address 0) will be OK, since they are binding to all local addresses. This is not limited to secondary addresses. If a new physical interface or pseudo-device is created, you will observe the same problem. > >-- >Regards. >+.....................pure personal opinion..........................+ > Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM > Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 >+.....................Kick ass VMS solution!.........................+ ------------------------------------------------------------- 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, 19 Jan 2000 04:24:34 -0400 Message-ID: <38857D5E.38ABB8BB@SMTP.DeltaTel.RU> Date: Wed, 19 Jan 2000 12:01:18 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWare 5.3-3 and SECONDARY IP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hello Geoff! Geoff Bryant wrote: > > "Ruslan R. Laishev" writes: > > > >Hi All! > > Some time ago I had had a some problem, which very puzzled me, it's > >related to secondary IP support implementation in the TCPWare TCP 5.3-3. > > > > We have a two member SCSI-cluster on a site, on the both node runs a > >number of internet applications like OSU HTTP,IUPOP3, MX and so on. For > >tolerance it is configured up to hundred secondary IPs (by netcu add > >secondary /cluster_lock). We expect that when node1 is down, node2 will > >accure a culster_lock and will continue to clients. > > It is correct that if node1 gfoes down, the secondary addresses it holds will > fail over to node2. Your comment about "contnue to clients" depends on teh > application. There is a bunch aplication wich can't restarting automaticaly after node2 getting a secondary IP: DNS, IUPOP3, SMTP etc - any appllication wich started as detached process but not by inetd. > > > The problem is if node2 have not cluster_lock at moment of startup > >internet applications then these application can't performs "bind" of > >soctes to these secondary IP. > > That is correct because the IP address does not exist on that system. It will > work if the application binds to all addresses, but if it binds only to the > explicit addresses it sees at startup, then there will be a problem. Sure. > > > My questions: > > 1) Who have the problem like it ? > > 2) How PSC plan to resolve this problem ? > > This is not something that PSC can resolve. It is a problem for the > application to be able to handle a new address on the system. Hmmm... Alright. Let me renaming a sentence "the problem" to the "unuseful of secondary IP". I suspect that PSC can resolve it by allowing of bind socket to this address and start real processing of packets to the secondary IP after obtatining a cluster_lock. > As I said, > applications which bind to INADDR_ANY (address 0) will be OK, since they are > binding to all local addresses. This is not limited to secondary addresses. > If a new physical interface or pseudo-device is created, you will observe the > same problem. Geoff, the first example of application wich will not work is TCPWare DNS. Because typical M$ Windoze resolver ignore answers from IP address wich is not match IP address in configuration. I think this functionality will take us ability to build pure "disaster tolerance" solutions. -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +.....................Kick ass VMS solution!.........................+ ================================================================================ Archive-Date: Wed, 19 Jan 2000 07:36:18 -0400 Sender: schreiber@process.com Date: Wed, 19 Jan 2000 07:32:47 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E45D7.D8C9D5D7.67@process.com> Subject: Re: TCPWare 5.3-3 and SECONDARY IP "Ruslan R. Laishev" writes: > > Geoff, the first example of application wich will not work is TCPWare >DNS. Because typical M$ Windoze resolver ignore answers from IP address >wich is not match IP address in configuration. > It is well known that DNS can't be used with secondary addresses, and this is the exact reason. DNS however doesn't really need the benefits of secondary addresses, since the protocol itself is designed with failure in mind. BTW: It's more general than 'ignore answers not in configuration". It's actually on a packet by packet basis. If it gets an answer for a query and it's not from the same IP address that it sent the query to, it's ignored. -Jeff ================================================================================ Archive-Date: Wed, 19 Jan 2000 07:56:09 -0400 Subject: Re: TCPWare 5.3-3 and SECONDARY IP From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <3885b01d@news.kapsch.co.at> Date: 19 Jan 2000 13:37:49 +0100 To: Info-TCPware@PROCESS.COM In article <38857D5E.38ABB8BB@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > Geoff, the first example of application wich will not work is TCPWare >DNS. Because typical M$ Windoze resolver ignore answers from IP address >wich is not match IP address in configuration. DNS is UDP and only UDP comm has this problem. TCP (eg. a DNS Zonetransfer) has not this problem (but maybe has another because the link has to be newly established after failover) And in this case, there is no difference between a) a secondary address b) a pseudo interface c) a real interface if this additional address is in the same subnet as the "primary" IP address. Consider having the primary IP address of the two servers in another IP subnet (which of course should be reachable via a router or you totally loose contact to the server which currently has not the secondary address). Especially check if GATED corrects the routing table in the server after aquiring the secondary address. > I think this functionality will take us ability to build pure "disaster >tolerance" solutions. If your client depends on this then yes. We found CISCO Router DNS Client, IRIX PCNFS Client and PROTEON Router TFTP Client to be so picky, that they won't work with such secondary addresses. But DNS is not the real problem. A Nameserver is allowed to be down. And that is the reason, why a DNS client has more than one server listed in its config. And I would like to see a better solution, too. Any idea, Geoff ? -- 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, 19 Jan 2000 08:58:38 -0400 Message-ID: <3885B919.289AA96E@SMTP.DeltaTel.RU> Date: Wed, 19 Jan 2000 16:16:09 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWare 5.3-3 and SECONDARY IP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Peter LANGSTOEGER wrote: > > In article <38857D5E.38ABB8BB@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > > Geoff, the first example of application wich will not work is TCPWare > >DNS. Because typical M$ Windoze resolver ignore answers from IP address > >wich is not match IP address in configuration. > > DNS is UDP and only UDP comm has this problem. Sure, there is another application wich use UDP - RADIUS. A yet another example: MX SMTP server, and M$ Exchange wich have tried to connect to IP address wich is not realy live because MX SMTP server must be restarted. And from other hand this dumb M$ Exchange don't work correctly with list of addresses. > TCP (eg. a DNS Zonetransfer) has not this problem (but maybe has another > because the link has to be newly established after failover) DNS Zonetransfer don't directly impact users. > > And in this case, there is no difference between > a) a secondary address > b) a pseudo interface > c) a real interface > if this additional address is in the same subnet as the "primary" IP address. Agree. > > Consider having the primary IP address of the two servers in another IP > subnet (which of course should be reachable via a router or you totally > loose contact to the server which currently has not the secondary address). > Especially check if GATED corrects the routing table in the server after > aquiring the secondary address. No-no-no-no - it's _not_routing_ related "situation". > > > I think this functionality will take us ability to build pure "disaster > >tolerance" solutions. > > If your client depends on this then yes. Peter, _every_ ISP under VMS/TCPware depends on this. Trust me. :-) > We found CISCO Router DNS Client, IRIX PCNFS Client and PROTEON Router TFTP > Client to be so picky, that they won't work with such secondary addresses. Let me imagine next situation ten NAS-es (with several hundred Async/Sync/ISDN ports), 10-15 logins request per second, when primary RADIUS server is down, NAS will switch to backup server. NAS give to dial-up clients address of a DNS servers, and every client will try to use DNS server on node1 firstly, and after some timeout will switch to second server. This situation cause to the some delaying in address resolving for example. A client call to support staff and ask "what a hell, why _your_ services too slow!!!" > > But DNS is not the real problem. A Nameserver is allowed to be down. And that > is the reason, why a DNS client has more than one server listed in its config. > > And I would like to see a better solution, too. Thanks for support! > Any idea, Geoff ? > > -- > 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 -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 19 Jan 2000 08:58:46 -0400 Message-ID: <3885BAFE.C5A49AA2@SMTP.DeltaTel.RU> Date: Wed, 19 Jan 2000 16:24:14 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWare 5.3-3 and SECONDARY IP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hello Jeff! Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > > Geoff, the first example of application wich will not work is TCPWare > >DNS. Because typical M$ Windoze resolver ignore answers from IP address > >wich is not match IP address in configuration. > > > > It is well known that DNS can't be used with secondary addresses, and > this is the exact reason. DNS however doesn't really need the benefits > of secondary addresses, since the protocol itself is designed with failure > in mind. Agreed. > > BTW: It's more general than 'ignore answers not in configuration". It's > actually on a packet by packet basis. If it gets an answer for a query and > it's not from the same IP address that it sent the query to, it's ignored. > > -Jeff Jeff, I have tried to say that it need to change pseudo/secondary_IP behaviour - your customers will have powerful solution, competitors of TCPWare/Multinet will have nothing :-). -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 19 Jan 2000 10:08:28 -0400 Subject: Re: TCPWare 5.3-3 and SECONDARY IP From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <3885d0a2$1@news.kapsch.co.at> Date: 19 Jan 2000 15:56:34 +0100 To: Info-TCPware@PROCESS.COM In article <3885B919.289AA96E@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: >Peter LANGSTOEGER wrote: >>In article <38857D5E.38ABB8BB@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: >>> Geoff, the first example of application wich will not work is TCPWare >>>DNS. Because typical M$ Windoze resolver ignore answers from IP address >>>wich is not match IP address in configuration. >> >>DNS is UDP and only UDP comm has this problem. > Sure, there is another application wich use UDP - RADIUS. We found our NFS clients (except IRIX PCNFS) to not have this problem, too. We found our time clients to not have this problem. And so on. >A yet another example: MX SMTP server ?? SMTP is TCP >and M$ Exchange wich have tried to connect to IP address wich is not >realy live because MX SMTP server must be restarted. Configure a name for the MX SMTP server in Exchange and enter all three addresses in BIND for this name. And bind MX to all addresses (as written in a previous post) which is default. >And from other hand this dumb M$ >Exchange don't work correctly with list of addresses. I wouldn't be suprised to find M$ products behave erratically, but this is behaviour unknown at our site. We use "mail.kapsch.co.at" as the name of a server the Exchange-Servers, NETSCAPE Clients and other SMTP mailservers do forward mails to. Said Name is entered in BIND with 6 IP addresses (each of the two servers is multihomed in two subnets and both subnets have its own secondary cluster alias address) and it works. I can send you a NETCU SHOW CONN if you like ;-) >> Consider having the primary IP address of the two servers in another IP >> subnet (which of course should be reachable via a router or you totally >> loose contact to the server which currently has not the secondary address). >> Especially check if GATED corrects the routing table in the server after >> aquiring the secondary address. > No-no-no-no - it's _not_routing_ related "situation". But if you choose to have the secondary address in another subnet than the primary address of the server(s), it will get a routing related situation. We do not use this here, but it is IMHO worth considering. >Peter, _every_ ISP under VMS/TCPware depends on this. Trust me. :-) Agreed on this (almost, not only VMS and VMS/ISP have this problem, every TCPIP stack and ISP is said to have this problem) and the rest of the mail. -- 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, 19 Jan 2000 10:28:05 -0400 Sender: schreiber@process.com Date: Wed, 19 Jan 2000 10:24:35 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E45EF.D88518C1.86@process.com> Subject: Re: TCPWare 5.3-3 and SECONDARY IP eplan@kapsch.net (Peter LANGSTOEGER) writes: > >I wouldn't be suprised to find M$ products behave erratically, but this >is behaviour unknown at our site. We use "mail.kapsch.co.at" as the name >of a server the Exchange-Servers, NETSCAPE Clients and other SMTP >mailservers do forward mails to. Said Name is entered in BIND with 6 IP >addresses (each of the two servers is multihomed in two subnets and both >subnets have its own secondary cluster alias address) and it works. >I can send you a NETCU SHOW CONN if you like ;-) > I've not completely followed what your doing, but have you considered looking into load balancing. You can't point DNS resolvers at a load balanced name, but you can point things that are configured to contact a server by name, rather than by ip address, you can setup the VMS servers as a load balanced cluster, and the result will be the least loaded systems address will be listed first in the answer. If a system goes away, it gets moved to the end of the list. Check the load balancing section in the docs. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 19 Jan 2000 10:35:26 -0400 Subject: Re: TCPWare 5.3-3 and SECONDARY IP From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <3885d850$1@news.kapsch.co.at> Date: 19 Jan 2000 16:29:20 +0100 To: Info-TCPware@PROCESS.COM In article <009E45EF.D88518C1.86@process.com>, Jeff Schreiber writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >> >>I wouldn't be suprised to find M$ products behave erratically, but this >>is behaviour unknown at our site. We use "mail.kapsch.co.at" as the name >>of a server the Exchange-Servers, NETSCAPE Clients and other SMTP >>mailservers do forward mails to. Said Name is entered in BIND with 6 IP >>addresses (each of the two servers is multihomed in two subnets and both >>subnets have its own secondary cluster alias address) and it works. >>I can send you a NETCU SHOW CONN if you like ;-) >> > > I've not completely followed what your doing, but have you considered > looking into load balancing. You can't point DNS resolvers at a load > balanced name, but you can point things that are configured to contact > a server by name, rather than by ip address, you can setup the VMS > servers as a load balanced cluster, and the result will be the least > loaded systems address will be listed first in the answer. If a system > goes away, it gets moved to the end of the list. > > Check the load balancing section in the docs. Thanks. Read. And no thank you (if it works in mixed UCX/TCPware environments I'll check again). -- 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, 19 Jan 2000 10:38:24 -0400 Sender: schreiber@process.com Date: Wed, 19 Jan 2000 10:34:54 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E45F1.49D48BFF.115@process.com> Subject: Re: TCPWare 5.3-3 and SECONDARY IP "Ruslan R. Laishev" writes: > > Jeff, I have tried to say that it need to change pseudo/secondary_IP >behaviour - your customers will have powerful solution, competitors of >TCPWare/Multinet will have nothing :-). > I've not looked into it since we actually added the pseudo interface support, but if I remember correctly, the DNS resolver problem wasn't an issue with that, only with the cluster alias failover. I can give a basic explination of the problem. The way cluster alias failover works, is the drivers know that it is to receive on the secondary address, but the applications don't know anything about it. It receives the data through the primary interface that the secondary address is part of. Since it's UDP, there really is no real context at the application level of where the datagram was sent to, so it basically sends it's response down the interface that it was read from. Since it's UDP, and a datagram is a datagram, and the drivers have no way of determining if the UDP datagram is a reply to some other datagram that was received, so it only knows to set the 'from' information on the datagram to be the address for the interface that it's being sent out of. So that's how the DNS response [or other UDP application] ends up with the ip address of the primary IP address for the interface, rather than the secondary. When you are dealing with pseudo interfaces, it has it's own interface, so if a UDP application is bound to each interface on the system, it might not be able to determine what IP address the datagram came to, but it does know what interface it came from, and sends it out that same interface. Since the Pseudo interfaces have their own seperate interfaces, the drivers know what address to say the datagram is coming from, and thus you get the response from the IP address that it was sent to. Now if you have any ideas on how to possibly improve the cluster alias failover support, I would be happy to hear more. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 19 Jan 2000 11:13:22 -0400 Message-ID: <3885D9AE.A7E8032E@SMTP.DeltaTel.RU> Date: Wed, 19 Jan 2000 18:35:10 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWare 5.3-3 and SECONDARY IP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Peter LANGSTOEGER wrote: > > In article <3885B919.289AA96E@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > >Peter LANGSTOEGER wrote: > >>In article <38857D5E.38ABB8BB@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > >>> Geoff, the first example of application wich will not work is TCPWare > >>>DNS. Because typical M$ Windoze resolver ignore answers from IP address > >>>wich is not match IP address in configuration. > >> > >>DNS is UDP and only UDP comm has this problem. > > Sure, there is another application wich use UDP - RADIUS. > > We found our NFS clients (except IRIX PCNFS) to not have this problem, too. > We found our time clients to not have this problem. And so on. It's mean that NFS client don't check IP address matching. > > >A yet another example: MX SMTP server > > ?? > SMTP is TCP Yes, SMTP is TCP and it's mean that MX SMTP server can't bind listener to secondary_IP and it's mean also that any smtp client in particulary M$ Exch can connect to this SMTP server. > > >and M$ Exchange wich have tried to connect to IP address wich is not > >realy live because MX SMTP server must be restarted. > > Configure a name for the MX SMTP server in Exchange and > enter all three addresses in BIND for this name. > And bind MX to all addresses (as written in a previous post) which is default. MX can't bind to all secondary addresses until a node can't get cluster_lock. MX can bind to INADDR_ANY address it's not the same as bind to several IP addresses. > > >And from other hand this dumb M$ > >Exchange don't work correctly with list of addresses. > > I wouldn't be suprised to find M$ products behave erratically, but this > is behaviour unknown at our site. We use "mail.kapsch.co.at" as the name > of a server the Exchange-Servers, NETSCAPE Clients and other SMTP > mailservers do forward mails to. Said Name is entered in BIND with 6 IP > addresses (each of the two servers is multihomed in two subnets and both > subnets have its own secondary cluster alias address) and it works. > I can send you a NETCU SHOW CONN if you like ;-) No thanks. I suspect that you have a several MX RR like MX , in this case M$ Echx can work, but it don't work correctly with ip name which have a several ip addresses. -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 19 Jan 2000 16:08:52 -0400 Message-ID: <38861E81.CB76D9BC@SMTP.DeltaTel.RU> Date: Wed, 19 Jan 2000 23:28:49 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWare 5.3-3 and SECONDARY IP Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > > Jeff, I have tried to say that it need to change pseudo/secondary_IP > >behaviour - your customers will have powerful solution, competitors of > >TCPWare/Multinet will have nothing :-). > > > > I've not looked into it since we actually added the pseudo interface > support, but if I remember correctly, the DNS resolver problem wasn't > an issue with that, only with the cluster alias failover. Yes. DNS is not the primary question is really discused in this topic. > > I can give a basic explination of the problem. The way cluster alias > failover works, is the drivers know that it is to receive on the secondary > address, but the applications don't know anything about it. It receives > the data through the primary interface that the secondary address is part > of. Since it's UDP, there really is no real context at the application > level of where the datagram was sent to, so it basically sends it's > response down the interface that it was read from. Since it's UDP, and > a datagram is a datagram, and the drivers have no way of determining if > the UDP datagram is a reply to some other datagram that was received, so > it only knows to set the 'from' information on the datagram to be the > address for the interface that it's being sent out of. So that's how > the DNS response [or other UDP application] ends up with the ip address of > the primary IP address for the interface, rather than the secondary. > > When you are dealing with pseudo interfaces, it has it's own interface, > so if a UDP application is bound to each interface on the system, it might > not be able to determine what IP address the datagram came to, but it does > know what interface it came from, and sends it out that same interface. > Since the Pseudo interfaces have their own seperate interfaces, the > drivers know what address to say the datagram is coming from, and thus > you get the response from the IP address that it was sent to. Yes. It's that reason of using PSD for UDP based applications, and secondary or PSD for TCP based application. 5.3-3 release notes give me limit for number of PSD - 255 devices, and no info about of "cluster_lock" for PSD. > > Now if you have any ideas on how to possibly improve the cluster alias > failover support, I would be happy to hear more. Oh, I'm really happy to offer next idea (let me demonstrate it with PSD): "netcu start/ip psd-XXX ... /cluster_lock" - create PSD and mark it as noactive interace, in the same time it must give ability to perform bind a socket to this interface. When cluster_lock is granted it's switched to active state the PSD-XXX interface. Its all. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +.....................Kick ass VMS solution!.........................+ ================================================================================ Archive-Date: Wed, 19 Jan 2000 18:04:47 -0400 Date: Wed, 19 Jan 2000 17:35:23 +0000 From: Sara.Appleyard@essential.co.uk Reply-To: Info-TCPware@process.com Subject: Assistance with programming SNMP Traps To: info-tcpware@process.com, support@process.com CC: Q-Process@essential.co.uk Message-ID: <90088CB087DBD21194870008C733B45D724142@NTESS005> MIME-Version: 1.0 Content-Type: text/plain Does anyone know of a company (contract programmers etc) with experience of programming SNMP traps with TCPware? We have a client with a requirement to trigger SNMP traps from a VMS-based security software package. The package in question collects specific security events from the host OpenVMS system and passes them onto a DCL command file from which other actions can be taken (one of which could be to run the executable (C???) that generates the SNMP trap. Many thanks Sara Appleyard Essential 01275 343199 ================================================================================ Archive-Date: Thu, 20 Jan 2000 03:02:12 -0400 Message-ID: <3886BC31.7C537910@SMTP.DeltaTel.RU> Date: Thu, 20 Jan 2000 10:41:37 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Assistance with programming SNMP Traps Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hello Sara! If you have not other candidats, you can consider me as potential contract programmers. Can you provide more details about of functionality is required? Sara.Appleyard@essential.co.uk wrote: > > Does anyone know of a company (contract programmers etc) with experience of > programming SNMP traps with TCPware? > > We have a client with a requirement to trigger SNMP traps from a VMS-based > security software package. The package in question collects specific > security events from the host OpenVMS system and passes them onto a DCL > command file from which other actions can be taken (one of which could be to > run the executable (C???) that generates the SNMP trap. > > Many thanks > > Sara Appleyard > Essential > 01275 343199 -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +.....................Kick ass VMS solution!.........................+ ================================================================================ Archive-Date: Fri, 21 Jan 2000 15:32:19 -0400 Date: Fri, 21 Jan 2000 15:28:18 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V543P010 To: TCPware-Announce@PROCESS.COM Message-ID: <01JKYZ4W34TU003JB2@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V543P010 Description: Fix for Outgoing Access Restrictions Release date: 21-JAN-2000 Versions: 5.4-3, 5.3-3, 5.3-2 ftp://ftp.process.com/support/54_3/drivers_v543p010.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- DRIVERS patch kit revision 1.0 for TCPware Version 5.4-3 1= 9-Jan-2000 Copyright =A9 1999-2000 Process Software Corporation This patch kit provides a new version of the TCPware Version 5.4 TC= PDRIVER for OpenVMS Alpha V7.0 and above. The Following change has been made: =09D/E 5350 - Changes made to the Outgoing Access Restrictions featur= e that corrects problems introduced in TCPware 5.4 a= nd DRIVERS_V533P050. =09Only systems using Outgoing Access Restrictions on OpenVMS Alpha V= 7.0 =09and above, with either TCPware Version 5.4 or DRIVERS_V533P050 on =09TCPware 5.3 need to upgrade to this patch kit. This patch kit also provides the following changes applicable to TC= Pware Version 5.3 previously provided in DRIVERS_V533P050: BGDRIVER - D/E 2298 - Modify behaviour of IO$_DEACCESS - D/E 3509 - Modified to allow DCL/Perl scripts to= work properly under the Netscape FastTrack= web server. - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. INETDRIVER - D/E 339 - Correct the output of an extra f= or output from REXEC - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. IPDRIVER - D/E 2213 - Fix routine which derives largest MTU= of all physical interfaces. This is us= ed by TCP to set the MSS advertised at conn= ection establishment. - D/E 2453 - EWA twisted pair Ethernet controllers= with the cable removed would hang TCPware = during startup. This problem has been corre= cted. - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. NTDRIVER - D/E 3330 - Drop any received data when closing. - D/E 1537 - Permanent NTA /w CLOSE_DASSGN cannot = be deleted. - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. TCPDRIVER - D/E 3872 - Recognize SYN packets in successive connections when old connection is in TIME_WAIT (RLOGIN clients no longer h= ang on successive connections) - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. UDPDRIVER - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. NOTE: You must reboot your system after installing this patch in or= der to load the new driver(s). The old versions of the driver(s) will be renamed to *.EXE_OLD. Once installed, you may undo this patch by renaming the file(s) bac= k to: TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE [End of ECO announcement] ================================================================================ Archive-Date: Tue, 25 Jan 2000 10:40:51 -0400 Subject: TCPWARE_FTP_220_REPLY From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <388db47c@news.kapsch.co.at> Date: 25 Jan 2000 15:34:36 +0100 To: Info-TCPware@PROCESS.COM As you can see with FTP.PROCESS.COM the new FTP server of TCPware V5.4 (or is it the FTP_V543P021 ECO only ?) does now use differently the logical TCPWARE_FTP_220_REPLY (and maybe some others, too) $ ty TCPWARE:FTP_ANNOUNCE.TXT This is a fileserver $ def/sys/ex TCPWARE_FTP_220_REPLY "@TCPWARE:FTP_ANNOUNCE.TXT" $ ftp localhost 220-@SYS$MANAGER:FTP_ANNOUNCE.TXT 220 node.domain.name (aaa.bbb.ccc.ddd) FTP-OpenVMS FTPD V5.4-3 (c) 1999 Process Software Corporation _Username [user]: with previous version(s) it used to be $ ftp localhost 220 This is a fileserver _Username [user]: So, what do you think ? Is it a bug, a new feature ? Is it documented ? (I just started to look up, but was so far unsuccessful) Should the customized 220 message come in addition to the standard 220 message or a replacement ? -- 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, 25 Jan 2000 10:47:58 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86024559ED@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPWARE_FTP_220_REPLY Date: Tue, 25 Jan 2000 10:44:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Looks like a bug. It should have displayed the text in the file. I will investigate, and file a defect report if I can reproduce the problem. One question - what is the protection on TCPWARE:FTP_ANNOUNCE.TXT? -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: Tuesday, January 25, 2000 9:35 AM To: Info-TCPware@PROCESS.COM Subject: TCPWARE_FTP_220_REPLY As you can see with FTP.PROCESS.COM the new FTP server of TCPware V5.4 (or is it the FTP_V543P021 ECO only ?) does now use differently the logical TCPWARE_FTP_220_REPLY (and maybe some others, too) $ ty TCPWARE:FTP_ANNOUNCE.TXT This is a fileserver $ def/sys/ex TCPWARE_FTP_220_REPLY "@TCPWARE:FTP_ANNOUNCE.TXT" $ ftp localhost 220-@SYS$MANAGER:FTP_ANNOUNCE.TXT 220 node.domain.name (aaa.bbb.ccc.ddd) FTP-OpenVMS FTPD V5.4-3 (c) 1999 Process Software Corporation _Username [user]: with previous version(s) it used to be $ ftp localhost 220 This is a fileserver _Username [user]: So, what do you think ? Is it a bug, a new feature ? Is it documented ? (I just started to look up, but was so far unsuccessful) Should the customized 220 message come in addition to the standard 220 message or a replacement ? -- 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, 25 Jan 2000 11:14:06 -0400 Subject: RE: TCPWARE_FTP_220_REPLY From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <388dc865@news.kapsch.co.at> Date: 25 Jan 2000 16:59:33 +0100 To: Info-TCPware@PROCESS.COM In article <63D30D6E10CFD11190A90000F805FE86024559ED@lespaul.process.com>, Richard Whalen writes: >Looks like a bug. Thank you. >It should have displayed the text in the file. In addition to the standard 220 message or instead ? With TCPware V5.3 and earlier it was "instead". But I can surely live with "in addition". >I will investigate, and file a defect report if I can reproduce the problem. As I wrote, check your own FTP server FTP.PROCESS.COM >One question - what is the protection on TCPWARE:FTP_ANNOUNCE.TXT? Doesn't matter. At the time this message is displayed, the FTP server is still in privileged (user "SYSTEM", uic "[REMACP]") mode. Nevertheless: (S:RWD,O:RWD,G,W) -- 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, 25 Jan 2000 12:30:18 -0400 Date: Tue, 25 Jan 2000 11:26:27 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000125112627.202000c2@process.com> Subject: RE: TCPWare and FTP David Morsberger writes: > >Does anyone how to configure the TCPWare FTP server to report unix style >directory listing? I am not sure what it does not understand about the info >returned by TCPWare. Tech Support for one of the FTP client stated: > Are you running TCPware V5.4-3? Earlier versions of TCPware did not support the UNIX-style listings. Otherwise, it should work to just define the logical as you did (be sure and specify at least /SYSTEM): $ define/system tcpware_ftp_unix_style_by_default true I just tried this on both VAX and Alpha and everything worked fine for me. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 25 Jan 2000 12:30:57 -0400 Date: Tue, 25 Jan 2000 11:27:11 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000125112711.202000c2@process.com> Subject: RE: TCPWARE_FTP_220_REPLY eplan@kapsch.net (Peter LANGSTOEGER) writes: > >$ ftp localhost >220-@SYS$MANAGER:FTP_ANNOUNCE.TXT [...] >So, what do you think ? Is it a bug, a new feature ? It's a bug that appears in the VAX version. We're looking into it. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 25 Jan 2000 15:43:45 -0400 Subject: RE: TCPWARE_FTP_220_REPLY From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <388e0946@news.kapsch.co.at> Date: 25 Jan 2000 21:36:22 +0100 To: Info-TCPware@PROCESS.COM In article <000125112711.202000c2@process.com>, Hunter Goatley writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >> >>$ ftp localhost >>220-@SYS$MANAGER:FTP_ANNOUNCE.TXT >[...] >>So, what do you think ? Is it a bug, a new feature ? > >It's a bug that appears in the VAX version. Nope. It's in the Alpha version, too. >We're looking into it. Thanks. -- 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, 25 Jan 2000 15:55:04 -0400 Date: Tue, 25 Jan 2000 14:51:15 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000125145115.202000c2@process.com> Subject: RE: TCPWARE_FTP_220_REPLY eplan@kapsch.net (Peter LANGSTOEGER) writes: > >>It's a bug that appears in the VAX version. > >Nope. It's in the Alpha version, too. > Strange. It worked OK for me on my Alpha, but failed on my VAX. >>We're looking into it. > I'll double-check both. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 25 Jan 2000 16:14:02 -0400 Subject: RE: TCPWARE_FTP_220_REPLY From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <388e0fba$1@news.kapsch.co.at> Date: 25 Jan 2000 22:03:54 +0100 To: Info-TCPware@PROCESS.COM In article <000125145115.202000c2@process.com>, Hunter Goatley writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >> >>>It's a bug that appears in the VAX version. >> >>Nope. It's in the Alpha version, too. >> >Strange. It worked OK for me on my Alpha, but failed on my VAX. I haven't tried a pure V5.4-3. I checked it with FTP_V543P02x (x=0,1) -- 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, 25 Jan 2000 16:16:26 -0400 Date: Tue, 25 Jan 2000 15:12:34 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000125151234.202000c2@process.com> Subject: RE: TCPWARE_FTP_220_REPLY eplan@kapsch.net (Peter LANGSTOEGER) writes: > >>Strange. It worked OK for me on my Alpha, but failed on my VAX. > >I haven't tried a pure V5.4-3. I checked it with FTP_V543P02x (x=0,1) > Ah, thanks for the info! Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 26 Jan 2000 08:28:04 -0400 Message-ID: <00dc01bf6800$477b12c0$0e0d10ac@CN02638.nbbs.nl> From: "Johan Parlevliet" Reply-To: Info-TCPware@process.com To: Subject: Anyone has TCPWARE and mounted NOVELL NFS 2.3 ? Date: Wed, 26 Jan 2000 14:21:39 +0100 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === We cannot get a NOVELL drive mounted on the VAX running TCPWARE v5.3-3 Novell is 4.11 servicepack 8 with nfs 2.3 Novell is saying something about port 1033 which TCPWARE should not = support Each time we try to mount a disk from novell server the RPC module on = the novell server crashes. We have to do unistop en unistart to try again Anybody knows about this or has the same products where NOVELL NFS = works. Met vriendelijke groet Johan Parlevliet NBBS Reizen BV E-mail: parlevjo@nbbs.nl Internet: http://www.nbbs.nl Tel: 071-5688706 Fax: 071-5688889 ================================================================================ Archive-Date: Thu, 27 Jan 2000 15:14:50 -0400 Subject: [TCPware V5.4-3] Location of NAMED.CONF From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <3890a1fd$1@news.kapsch.co.at> Date: 27 Jan 2000 20:52:29 +0100 To: Info-TCPware@PROCESS.COM We all read that the TCPware V5.4-3 BIND implementation is now BIND 8 (vs BIND 4 in previous TCPware versions) and BIND 8 requires a NAMED.CONF (instead of a NAMED.BOOT with BIND 4). In the doc there is a statement, that CNFNET does convert NAMED.BOOT to NAMED.CONF (or creates a default - caching only - NAMED.CONF if NAMED.BOOT isn't there). In fact, it is STARTNET, too. Both of them invoke (via the DNS_CONTROL.COM) the DNS_CONVERSION_TOOL.EXE to get the job done. BUT: It creates the NAMED.CONF in SYS$COMMON instead of SYS$SPECIFIC (or the same location as the NAMED.BOOT is/was). As I see a nameserver configuration not cluster related but node specific, I see this behaviour as a bug. Comments ? -- 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, 27 Jan 2000 17:09:51 -0400 From: "John O'Neil" Reply-To: Info-TCPware@process.com Subject: Mount failure from NFS Client Date: Thu, 27 Jan 2000 16:50:41 -0500 Message-ID: <86qi8j$l7j$1@sigma.intranet.com> To: Info-TCPware@PROCESS.COM I'm running TCPWare V5.3-3 on a VAX 7000 as my NFS server. I'm using the NFS Maestro product on my NT client trying to map a drive to the VMS host. My export looks like this: Path Directory Host(s) ---- --------- ------- /vms/jetform DISK$DEVEL:[JETFORM] ip address of nt workstation I get the error message: %%%%%%%%%%%% NFSD 27-JAN-2000 15:38:27.38 %%%%%%%%%%%% %PCNFSD-E-AUTHFAIL, failed to authorize, username JONEIL, from host multifax1 I've tried with and without a proxy setup on the VMS host. Since the proxy HELP refers to Unix gid and uid fields, do I even need the proxy entry for a nt client? The NFS Maestro software allows for a username and password field, which I input my VMS username and password. Any help is appreciated. John O'Neil ACI Corporate Banking Group Technical Services Manager 617.796.3105 (Voice) 617.243.8605 (Fax) joneil@intranet.com ================================================================================ Archive-Date: Thu, 27 Jan 2000 17:17:51 -0400 Message-ID: <4.2.2.20000127151106.00aaf990@mehlhop.org> Date: Thu, 27 Jan 2000 15:14:15 -0700 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: Mount failure from NFS Client In-Reply-To: <86qi8j$l7j$1@sigma.intranet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed NFS ALWAYS requires a gid/uid I am not sure how Maestro assigns it. I use ReflectionNFS and when the PC boots or you log in on NT it asks you for a system that will assign you a gid/uid pair with a username and password. TCPware nfs server can reply with that information if you have created it. Jim At 04:50 PM 1/27/00 -0500, you wrote: >I'm running TCPWare V5.3-3 on a VAX 7000 as my NFS server. I'm using the >NFS Maestro product on my NT client trying to map a drive to the VMS host. >My export looks like this: > >Path Directory Host(s) >---- --------- ------- >/vms/jetform DISK$DEVEL:[JETFORM] ip address of nt >workstation > >I get the error message: > >%%%%%%%%%%%% NFSD 27-JAN-2000 15:38:27.38 %%%%%%%%%%%% >%PCNFSD-E-AUTHFAIL, failed to authorize, username JONEIL, from host >multifax1 > >I've tried with and without a proxy setup on the VMS host. Since the proxy >HELP refers to Unix gid and >uid fields, do I even need the proxy entry for a nt client? The NFS Maestro >software allows for a username and password field, which I input my VMS >username and password. > >Any help is appreciated. > >John O'Neil >ACI Corporate Banking Group >Technical Services Manager >617.796.3105 (Voice) >617.243.8605 (Fax) >joneil@intranet.com > > > > > ================================================================================ Archive-Date: Fri, 28 Jan 2000 08:40:22 -0400 Sender: goatley@triton.process.com Message-ID: <63D30D6E10CFD11190A90000F805FE86023A5EB4@LESPAUL> From: Tom Ricci Reply-To: Info-TCPware@process.com To: Info-TCPware Subject: Online DNS Analysis: Free DNSworks Beta Now Available from Process Date: Fri, 28 Jan 2000 08:30:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Online DNS Analysis: Free DNSworks Beta Now Available. Process Software has announced the availability of an online domain analysis and optimization service that identifies DNS configuration errors and recommends solutions. Called DNSworks, the service is currently available free during a 2 week beta period starting today. To obtain the service, go to http://dnsworks.process.com and complete the first time user subscription form. Once completed, you simply add the domains to be tested and run the analysis online. DNSworks checks a number of different DNS files, including A Records, CNAME records, MX records, NS records, PTR records, and others. If DNS errors are detected, the service also offers recommended solutions to fix the problems. Reports are generated in HTML and can be viewed online and/or sent back to you via email. The entire analysis is completed in minutes. Be sure to read the "zone transfer policy" so that your DNS server is set up to transfer files and allow you to run the analysis. If you are not responsible for DNS administration at your organization, please forward this message to the administrator. This service will be free only during the beta period. Beta testers who complete the feedback form will receive a gift and entered into a drawing for a Palm Pilot. We appreciate your participation. ======================================= Tom Ricci, Director of Marketing Communications Process Software Corporation 959 Concord St., Framingham, MA 01701 (508) 626-7546/FAX: (508) 879-0042 ricci@process.com / www.process.com ======================================= ================================================================================ Archive-Date: Fri, 28 Jan 2000 11:48:52 -0400 Date: Fri, 28 Jan 2000 11:49:34 -0500 (EST) From: Gary Reynolds Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: PC Clients time setting changing to Incorrect Date & Time In-Reply-To: <3877AC8F.14933CCD@SMTP.DeltaTel.RU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm a new TCPware user ... Currently running TCPware 5.4-3 patched to FTP - 021 and NAMED - 010. On an Alphaserver 2100 VMS 6.2 1H2 - DecNet IV system. This is configured Slave to a SCO Unixware 2.1.2 Internet server. Telnet, FTP, XDM, POP3D, SNMPD, and perhaps relevant to my question, TIMED and NTPD. Additionally all users are connected to a Novell NETWARE V4.1 LAN. Don't know if this is important or related to what I'm going to ask -- but thought I'd mention it just in case. Since either the Year 2000 rollover or the near concurrent upgrade to TCPware 5.4, client PCs have been reporting that the Date and Time settings on them have been randomly changing. Typically some arbitrary date or time in 1994 or 1995. Most of the PC's are accessing the Alpha via Telnet client software only and use the Netware LAN for most Internet Mail and Browsing. My questions are : Is anyone experiencing anything similar ? Is there possibly some component of TCPware affecting this and perhaps needs set or configured ? Is it more likely originating with the Master node SCO server ? Any help is sincerely appreciated. This problem does have some more troublesome results for our staff using proprietary software to external service providers such as governmental agencies. They've been working around by re-setting the Date & Time settings on the PC's before connecting to the external host. I just want to make sure it is not a TCPware issue. Thanks, gary greynold@waynesburg.edu ================================================================================ Archive-Date: Sat, 29 Jan 2000 08:31:45 -0400 From: David Morsberger Reply-To: Info-TCPware@process.com Subject: Re: TCPWare and FTP Date: Sat, 29 Jan 2000 08:25:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Just checked and we have V5.3-2. How do we upgrade our new machine (~2months)? > From: Hunter Goatley > Organization: Info-Tcpware<==>Vmsnet.Networks.Tcp-Ip.Tcpware Gateway > Newsgroups: vmsnet.networks.tcp-ip.tcpware > Date: Tue, 25 Jan 2000 11:26:27 -0600 > Subject: RE: TCPWare and FTP > > David Morsberger writes: >> >> Does anyone how to configure the TCPWare FTP server to report unix style >> directory listing? I am not sure what it does not understand about the info >> returned by TCPWare. Tech Support for one of the FTP client stated: >> > Are you running TCPware V5.4-3? Earlier versions of TCPware did not > support the UNIX-style listings. > > Otherwise, it should work to just define the logical as you did (be > sure and specify at least /SYSTEM): > > $ define/system tcpware_ftp_unix_style_by_default true > > I just tried this on both VAX and Alpha and everything worked fine for > me. > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Sat, 29 Jan 2000 11:25:27 -0400 Date: Sat, 29 Jan 2000 10:21:43 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000129102143.202000c2@process.com> Subject: Re: TCPWare and FTP David Morsberger writes: > >Just checked and we have V5.3-2. How do we upgrade our new machine >(~2months)? > If you have a maintenance contract, you should have received the V5.4-3 distribution a couple of months ago. If you did not receive the new distribution, contact your sales rep or send mail to . Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Mon, 31 Jan 2000 08:36:24 -0400 Reply-To: Info-TCPware@process.com From: "Theresa Campbell" To: Subject: RE: PC Clients time setting changing to Incorrect Date & Time Date: Mon, 31 Jan 2000 08:35:21 -0500 Message-ID: <001c01bf6bf0$064b8980$32026b83@tol.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: I thought it was just me! I can't vouch for version #, but I've noticed the same thing on my PC - I thought maybe someone was gaining physical access and mucking with things, but this sounds like it may be more plausible. Theresa Campbell, Littleton Information Systems Manager 37 Shattuck Street, Littleton, MA 01460 theresa@ma.ultranet.com FAX 978-952-2718 PHONE 978-952-2777 -----Original Message----- From: Gary Reynolds [mailto:greynold@waynesburg.edu] Sent: Friday, January 28, 2000 11:50 AM To: Info-TCPware@process.com Subject: PC Clients time setting changing to Incorrect Date & Time Hello, I'm a new TCPware user ... Currently running TCPware 5.4-3 patched to FTP - 021 and NAMED - 010. On an Alphaserver 2100 VMS 6.2 1H2 - DecNet IV system. This is configured Slave to a SCO Unixware 2.1.2 Internet server. Telnet, FTP, XDM, POP3D, SNMPD, and perhaps relevant to my question, TIMED and NTPD. Additionally all users are connected to a Novell NETWARE V4.1 LAN. Don't know if this is important or related to what I'm going to ask -- but thought I'd mention it just in case. Since either the Year 2000 rollover or the near concurrent upgrade to TCPware 5.4, client PCs have been reporting that the Date and Time settings on them have been randomly changing. Typically some arbitrary date or time in 1994 or 1995. Most of the PC's are accessing the Alpha via Telnet client software only and use the Netware LAN for most Internet Mail and Browsing. My questions are : Is anyone experiencing anything similar ? Is there possibly some component of TCPware affecting this and perhaps needs set or configured ? Is it more likely originating with the Master node SCO server ? Any help is sincerely appreciated. This problem does have some more troublesome results for our staff using proprietary software to external service providers such as governmental agencies. They've been working around by re-setting the Date & Time settings on the PC's before connecting to the external host. I just want to make sure it is not a TCPware issue. Thanks, gary greynold@waynesburg.edu ================================================================================ Archive-Date: Mon, 31 Jan 2000 11:17:43 -0400 Date: Mon, 31 Jan 2000 11:18:14 -0500 (EST) From: Gary Reynolds Reply-To: Info-TCPware@process.com To: Theresa Campbell CC: Info-TCPware@process.com Subject: RE: PC Clients time setting changing to Incorrect Date & Time In-Reply-To: <001c01bf6bf0$064b8980$32026b83@tol.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Theresa, Are there any similarities to what I've listed as my configuration on the Server side (not the PC's) that maybe establishes a connection. For example : TCPware version, SLAVE config of the Alphaserver to a Primary alternative UNIX or whatever server, Active TCPware components ? This may be important to resolving for the Process SW Tech Support staff ... Could you find out or get me in touch with your Network person ? thanks, gary On Mon, 31 Jan 2000, Theresa Campbell wrote: > I thought it was just me! I can't vouch for version #, but I've noticed the > same thing on my PC - I thought maybe someone was gaining physical access > and mucking with things, but this sounds like it may be more plausible. >