Archive-Date: Mon, 1 May 2000 12:53:42 -0500 Subject: Re: SMTP relay From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <390db62d$1@news.kapsch.co.at> Date: 1 May 2000 18:51:57 +0200 To: Info-TCPware@PROCESS.COM In article <3909f3e4.3360181@news.wku.edu>, goathunter@PROCESS.COM (Hunter Goatley) writes: >On Fri, 28 Apr 2000 10:33:32 -0700, "drod" > wrote: >>Platform: Alpha 2100 >>System: Open-VMS V6.2 >> >>TCPWare for OpenVMS V5.2-3 >> >>We are setup up with the "SMTP RELAY" = NONE (default) >>Yet we can send email with a bogus login and password using our mail server >>shown above. >>When a test message is sent: >>The recieved message's header shows: Recieved: from: our.org >>(mail.our.org[our IP])... >>This is something we would like to get resolved and NOT alow anyone to use >>our mail server to send out mail. > >Upgrade to TCPware V5.4-3. The SMTP component in earlier versions >did not have any anti-relay features built-in. Or upgrade to MX (V5.1A) and use any IP stack in any version you like below. -- 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, 2 May 2000 06:37:03 -0500 Message-ID: From: Kevin Phillip Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: IPAW future directions Date: Tue, 2 May 2000 11:34:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Hi there, Where can I get more info on OpenVMS 7.3?? I've checked Digital's website, but found nothing. Maybe I'm looking in the wrong place. Thanks, Kevin... -----Original Message----- From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU] Sent: 19 April 2000 14:51 To: Info-TCPware@PROCESS.COM Subject: IPAW future directions Hi All, PSC! I known that in the next VMS release (7.3 - Kestrel, at spring 2000) will present LDAP server as a part of OS (covered by VMS license), is there any works in this direction on PSC? I just wondering :-) -- 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 + *********************************************************************** 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: Tue, 2 May 2000 08:59:32 -0500 Subject: RE: IPAW future directions From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <390ed030$1@news.kapsch.co.at> Date: 2 May 2000 14:55:12 +0200 To: Info-TCPware@PROCESS.COM In article , Kevin Phillip writes: >Where can I get more info on OpenVMS 7.3?? Usually at DECUS events, at DECUS webservers (housing the DECUS prentations), at your DECrep after signing a NDA (non disclosure agreement), maybe from a DEC executive/product manager via mail (check DEJA archive for their mailaddr), maybe at the newsgroup COMP.OS.VMS, maybe from a friend participating in a non-public beta program and finally maybe at DEC's webserver (white papers, public beta tests). > I've checked Digital's website, >but found nothing. Maybe I'm looking in the wrong place. Ok. Still, nothing on the website. Kismet. Try the other options. But here is the wrong place... -- 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, 2 May 2000 09:44:31 -0500 Message-ID: <390ED7B6.1C4A41@SMTP.DeltaTel.RU> Date: Tue, 02 May 2000 17:27:18 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: IPAW future directions Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM You can find contact at deja news site by: Dave Holmes, LDAP, in comp.os.vms forum. Kevin Phillip wrote: > > Hi there, > > Where can I get more info on OpenVMS 7.3?? I've checked Digital's website, > but found nothing. Maybe I'm looking in the wrong place. > > Thanks, > > Kevin... > > -----Original Message----- > From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU] > Sent: 19 April 2000 14:51 > To: Info-TCPware@PROCESS.COM > Subject: IPAW future directions > > Hi All, PSC! > > I known that in the next VMS release (7.3 - Kestrel, at spring 2000) > will present > LDAP server as a part of OS (covered by VMS license), is there any works in > this > direction on PSC? > > I just wondering :-) > > -- > 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 + > > *********************************************************************** > 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. > > *********************************************************************** -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Tue, 2 May 2000 10:08:27 -0500 Message-ID: From: "Garrido, Ramon, Mr, HQAFCEE" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: IPAW future directions Date: Tue, 2 May 2000 09:05:59 -0500 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === More like the winter of 2001 according to tech-support -----Original Message----- From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU] Sent: Tuesday, May 02, 2000 8:27 AM To: Info-TCPware@process.com Subject: Re: IPAW future directions You can find contact at deja news site by: Dave Holmes, LDAP, in comp.os.vms forum. Kevin Phillip wrote: > > Hi there, > > Where can I get more info on OpenVMS 7.3?? I've checked Digital's website, > but found nothing. Maybe I'm looking in the wrong place. > > Thanks, > > Kevin... > > -----Original Message----- > From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU] > Sent: 19 April 2000 14:51 > To: Info-TCPware@PROCESS.COM > Subject: IPAW future directions > > Hi All, PSC! > > I known that in the next VMS release (7.3 - Kestrel, at spring 2000) > will present > LDAP server as a part of OS (covered by VMS license), is there any works in > this > direction on PSC? > > I just wondering :-) > > -- > 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 + > > *********************************************************************** > 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. > > *********************************************************************** -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Tue, 2 May 2000 10:11:52 -0500 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: IPAW future directions Message-ID: Date: Tue, 2 May 2000 17:54:28 +0400 To: Info-TCPware@PROCESS.COM Peter LANGSTOEGER wrote in message <390ed030$1@news.kapsch.co.at>... >In article , Kevin Phillip writes: >>Where can I get more info on OpenVMS 7.3?? > >Usually at DECUS events, at DECUS webservers (housing the DECUS prentations), >at your DECrep after signing a NDA (non disclosure agreement), maybe from a >DEC executive/product manager via mail (check DEJA archive for their mailaddr), >maybe at the newsgroup COMP.OS.VMS, maybe from a friend participating in a >non-public beta program and finally maybe at DEC's webserver (white papers, >public beta tests). > >> I've checked Digital's website, >>but found nothing. Maybe I'm looking in the wrong place. > >Ok. Still, nothing on the website. Kismet. Try the other options. >But here is the wrong place... Why? I suspected that any SW-vendor worked in VMS area must know more than end-user, and from other hand this forum monitored by PSC. + C U, SysMan at DLS ...................................................+ http://www.radiusvms.com | Cel: +7 (901) 971-3222 http://www.levitte.org/~rlaishev | Fax: +7 (812) 115-1035 + Flying by Su-27........................................ Frying on VMS + ================================================================================ Archive-Date: Tue, 2 May 2000 12:34:55 -0500 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: IPAW future directions Message-ID: Date: Tue, 2 May 2000 19:45:40 +0400 To: Info-TCPware@PROCESS.COM Garrido, Ramon, Mr, HQAFCEE wrote in message ... > === The original message was multipart MIME === > === All non-text parts (attachments) have been removed === > >More like the winter of 2001 according to tech-support What is source of your information ? :) + C U, SysMan at DLS ...................................................+ http://www.radiusvms.com | Cel: +7 (901) 971-3222 http://www.levitte.org/~rlaishev | Fax: +7 (812) 115-1035 + Flying by Su-27........................................ Frying on VMS + ================================================================================ Archive-Date: Tue, 2 May 2000 13:19:13 -0500 Message-ID: From: "Garrido, Ramon, Mr, HQAFCEE" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: IPAW future directions Date: Tue, 2 May 2000 12:16:51 -0500 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === call 800-354-9000 Digitals' tech-support (software updates). I wanted to know if we should upgrade to 7.2-1H2 from 7.1-1H2, but there is no real advantage in our case because of the current hardware and we're not planning to install the Galaxy software. Also 7.2 seems to need a list of patches. I was wondering if 7.3 would include all the patches, but Tech-Support told me that 7.3 will be coming out early next year. They also told me that they will be dropping primary support for 7.1, but keeping secondary support. It is very possible that you might call and get a different answer, because it has happen to me before (sometimes its only rumors or their database has not been updated or just been updated or some other vague reason). In any case, I believe that they should guide you to the nearest truth. -----Original Message----- From: Ruslan R. Laishev [mailto:laishev@dls.net] Sent: Tuesday, May 02, 2000 10:46 AM) To: Info-TCPware@process.com Subject: Re: IPAW future directions Garrido, Ramon, Mr, HQAFCEE wrote in message ... > === The original message was multipart MIME === > === All non-text parts (attachments) have been removed === > >More like the winter of 2001 according to tech-support What is source of your information ? :) + C U, SysMan at DLS ...................................................+ http://www.radiusvms.com | Cel: +7 (901) 971-3222 http://www.levitte.org/~rlaishev | Fax: +7 (812) 115-1035 + Flying by Su-27........................................ Frying on VMS + ================================================================================ Archive-Date: Tue, 2 May 2000 13:32:58 -0500 Sender: schreiber@process.com Date: Tue, 2 May 2000 13:31:27 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E97C3.2E4AF3B6.75@process.com> Subject: RE: IPAW future directions "Garrido, Ramon, Mr, HQAFCEE" writes: >They also told me that they will be dropping primary support for 7.1, but >keeping secondary support. Steve Hoffmans OpenVMS Futures and Technical Update given at DECUS Europe mentioned that 7.1-2 was designed for what he called a "Landing Zone" release. A release to go with if you want to stay on one for a while. $0.02 if anyone cared :) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 5 May 2000 12:31:46 -0500 Message-ID: <3912F177.19C2938D@SMTP.DeltaTel.RU> Date: Fri, 05 May 2000 20:06:15 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: ...... on worm-virus get via e-mail Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Under TCPWare-TCP 5.4-3/SMTP the same problem. David Mathog wrote: > > In article <4.3.1.2.20000505083253.01a70170@sys4.mehlhop.org>, Jim Mehlhop writes: > >Yes > > > > > >add the line > > > > > >:Subject: ILOVEYOU * * Y > > > > > >for example:-) > > > > Doesn't work for me, I added these just below the :Message-ID: lines > > :Subject: <*ILOVEYOU*> > :Subject: <*JOKE*> > > or > > :Subject: <*ILOVEYOU*> * * Y > :Subject: <*JOKE*> * * Y > > or > > :Subject: ILOVEYOU * * Y > :Subject: JOKE * * Y > > or > > Subject: ILOVEYOU > Subject: JOKE > > and restarted the server each time. ILOVEYOU subject messages go right through. > All tests were sent from mathog@seqaxp to "mathog@seqaxp.bio.caltech.edu". > > Process Software MultiNet V4.2 Rev A-X, COMPAQ AlphaServer DS10 466 MHz, OpenVMS AXP V7.2-1 > > I'd really like to know the right combination soon since I've found 10 > users with these mail messages already. > > Regards, > > David Mathog > mathog@seqaxp.bio.caltech.edu > Manager, sequence analysis facility, biology division, Caltech -- 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: Fri, 5 May 2000 12:39:12 -0500 Date: Fri, 5 May 2000 11:37:47 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000505113747.202000ba@process.com> Subject: Re: ...... on worm-virus get via e-mail "Ruslan R. Laishev" writes: > >Under TCPWare-TCP 5.4-3/SMTP the same problem. > And the same solution, which is the correct line: :Subject: ILOVEYOU Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 5 May 2000 14:26:01 -0500 Message-ID: <39130C32.CBF60ABB@SMTP.DeltaTel.RU> Date: Fri, 05 May 2000 22:00:18 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: ...... on worm-virus get via e-mail Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hunter Goatley wrote: > > "Ruslan R. Laishev" writes: > > > >Under TCPWare-TCP 5.4-3/SMTP the same problem. > > > And the same solution, which is the correct line: > > :Subject: ILOVEYOU Thanks. :-) > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www2.wku.edu/hunter/ -- 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: Fri, 5 May 2000 16:56:17 -0500 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: ...... on worm-virus get via e-mail Message-ID: <2cGQ4.9799$UF3.7380876@news-east.usenetserver.com> Date: Sat, 6 May 2000 00:34:13 +0400 To: Info-TCPware@PROCESS.COM Hmmm... It looks like a parser or a docs problem: Follows work: :Subject: *ILOVEYOU* Follows don't work: :Subject: *ILOVEYOU* y "Spam from <%s> rejected" Ruslan R. Laishev wrote in message <39130C32.CBF60ABB@SMTP.DeltaTel.RU>... >Hunter Goatley wrote: >> >> "Ruslan R. Laishev" writes: >> > >> >Under TCPWare-TCP 5.4-3/SMTP the same problem. >> > >> And the same solution, which is the correct line: >> >> :Subject: ILOVEYOU > Thanks. :-) >> >> Hunter >> ------ >> Hunter Goatley, Process Software, http://www.process.com/ >> http://www2.wku.edu/hunter/ > >-- >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: Sat, 6 May 2000 11:45:16 -0500 Sender: schreiber@process.com Date: Sat, 6 May 2000 11:43:31 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E9AD8.C40BE9ED.5@process.com> Subject: Re: ...... on worm-virus get via e-mail "Ruslan R. Laishev" writes: > >Hmmm... > It looks like a parser or a docs problem: >Follows work: >:Subject: *ILOVEYOU* > >Follows don't work: >:Subject: *ILOVEYOU* y "Spam from <%s> rejected" > I don't have the TCPware docs in front of me, but I believe they are the same as Multinet for this section. ----------------------------- Mail rejection rules have two formats: :RFC822_header pattern This format causes rejection of any mail in which a line with the specified header matches the given pattern. The following rejection message is sent to the client: 554 Message rejected due to header contents Note! Use caution when rejecting mail based on header contents. No other criteria are considered during rejection processing. from_user ip_address to_user action action_data ------------------------------ You can reject on Header field patterns, or have actions and action_data when filtering MAIL FROM, RCPT to and all that. So given the above, your first example is correct. Your second example your mixing the two types of rules. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Sat, 6 May 2000 21:19:58 -0500 Message-ID: <39148D5C.F971A4E1@SMTP.DeltaTel.RU> Date: Sun, 07 May 2000 01:23:40 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: ...... on worm-virus get via e-mail Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > >Hmmm... > > It looks like a parser or a docs problem: > >Follows work: > >:Subject: *ILOVEYOU* > > > >Follows don't work: > >:Subject: *ILOVEYOU* y "Spam from <%s> rejected" > > > > I don't have the TCPware docs in front of me, but I believe they are the > same as Multinet for this section. Sorry, I checked docs again, YOU and Hunter are right, I was wrong, but why I have not any messages related the wrong syntax ? He-he. > > ----------------------------- > Mail rejection rules have two formats: > > :RFC822_header pattern > > This format causes rejection of any mail in which a line with the specified > header matches the given pattern. The following > rejection message is sent to the client: > > 554 Message rejected due to header contents > > Note! Use caution when rejecting mail based on header contents. No other > criteria are considered during rejection > processing. > > from_user ip_address to_user action action_data > ------------------------------ > > You can reject on Header field patterns, or have actions and action_data > when filtering MAIL FROM, RCPT to and all that. > > So given the above, your first example is correct. Your second example > your mixing the two types of rules. > > -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 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Mon, 8 May 2000 18:27:40 -0500 Date: Mon, 08 May 2000 18:25:32 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SNMPD_V543P020 To: TCPware-Announce@PROCESS.COM Message-ID: <01JP60SX86HE003XM4@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: SNMPD_V543P020 Description: Fix default route reporting when walking MIB tree. Release date: 8-MAY-2000 Ranking: 3 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/snmpd_v543p020.zip To search the TCPware ECO database, please visit the following URL: http://www.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. ----------------------------------------------------------- SNMPD Patch kit (revision 2.0) for TCPware version 5.4-3 March 6, 2000 Copyright (c) 2000, by Process Software Corporation This VMSinstallable saveset provides a new version of SNMPD for TCPware for OpenVMS. SNMP must be shut down before installing You must restart SNMP after installation. The following changes have been made: Only report the first default route that is not possibily down. This allows the MIB tree to be walked when there are multiple default routes, which fixes DE 765. Previous changes included in this patch: Use the new mechanism in DRIVERS_V543P010.A to obtain the interfaces counters InOctets and OutOctets. This fixes DE5550. [End of ECO announcement] ================================================================================ Archive-Date: Tue, 9 May 2000 16:28:56 -0500 Date: Tue, 09 May 2000 16:26:47 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P060 To: TCPware-Announce@PROCESS.COM Message-ID: <01JP7AY1P8S200468O@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_V543P060 Description: Allow /IMAGE=size to write fixed length records other than 512 Release date: 9-MAY-2000 Ranking: 3 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p060.zip To search the TCPware ECO database, please visit the following URL: http://www.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 6.0) for TCPware version 5.4-3 3-May-2000 Copyright (c) 2000, by Process Software Corporation This VMSinstallable saveset provides a new versions of FTP_CONTROL.COM, FTP_LISTENER.EXE, and FTP_SERVER.EXE for TCPware for OpenVMS. TCPWare V5.4-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made in this kit: FTP_SERVER.EXE - Allow /IMAGE=size to write out files with fixed length records of other than 512 bytes (DE 6055) The following changes from previous kits also in this kit: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) 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. - Correct a problem with FTP_V543P030 that could cause the TCPware_FTP process to consume channels. 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) - When the logical TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC is defined to TRUE files with variable length records and carriage return carriage control will NOT have a new line character inserted after each line when the file is transfered in image (binary) mode. This logical is now defined to be TRUE by default in FTPSERVER_DTP.COM, returning to the behavior present in TCPWare 5.3 (DE 5709) - Correct a problem that can occur when deleting files on a VAX from an NT system where the error "%LIB-F-INVSTRDES, invalid string descriptor" could occur. (DE 5722) - Correct a problem when TCPWARE_FTP__ROOT is defined to be disk:[dir.] /translation=conceal that would cause the user to be denied access to directories that previous versions of FTP did not deny access to. (DE5670) - Correct a problem with deleting wildcarded files in Unix mode. (DE 5734) - Correct a problem with displaying the directory in the 150 reply message in Unix mode. (DE 5736) - Correct a problem with the /IMAGE=size qualifier on the target file of a PUT command. (DE 6055) - Correct a problem with recognizing that TCPWARE_FTP__ROOT being defined as * means no restrictions. (DE 6058) After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Tue, 9 May 2000 18:28:29 -0500 Return-Path: Subject: Re: MX problems since TCPware V5.4-3 From: eplan@kapsch.net Reply-To: Info-TCPware@process.com Message-ID: <39188f7e$1@news.kapsch.co.at> Date: 10 May 2000 00:21:50 +0200 To: Info-TCPware@PROCESS.COM In article <38f05347$1@news.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >This week, I had a lot mails hanging (mostly to .CH addresses) in my MX queue >and wondered why. and I still wonder... >They all had the error message "connection timed out". > >Contacting the affected mailservers (after a NSLOOKUP -type=MX) by hand >(TELNET to TCP port 25) showed no problem. So, I did write a couple of >(small) mails and they did hang, too. It seems, it was not a problem with >mailsize. > >I did then write testmails from another node (with UCX) and the mails >got through. So, I enabled a UCX node in my cluster to run a few SMTP >agents and voila all mails got out (just like the other umpteen hundreds >mails per day which gets delivered without problems). > >Now, I'm a bit of surprised and disappointed. And I'm also surprised to see an "EPLAN-only" problem again :-( >I use MX V5.1-3 (= V5.1-A), TCPware V5.4-3 (with DRIVERS ECO 1.0). > >Next steps are, I upgrade to the most current versions of MX (which should >be no issue) and TCPware ECOs (eg. DRIVERS 2.0), but I also ask here: I run now MX V5.1-A with both ECOs. No change in this behaviour. But I haven't expected one... >Is there a known problem in TCPware V5.4-3 which effects MX mail delivery ? Error seen with TCPDUMP is: Tcpdump: listening on IPA0: 00:03:49.752833 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 482163 563:482165023(1460) ack 1527593 win 4096 (DF) 00:04:28.187311 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 (1460) ack 1 win 4096 (DF) 00:05:06.621932 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 (1460) ack 1 win 4096 (DF) 00:05:45.056497 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 (1460) ack 1 win 4096 (DF) 00:06:23.491005 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 (1460) ack 1 win 4096 (DF) 00:07:01.928655 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 (1460) ack 1 win 4096 (DF) 00:07:40.380288 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 (1460) ack 1 win 4096 (DF) and so on (if you want/need I'll get a complete mail dialog in TCPDUMP) >I remember, having problems with MX deliveries, the first week after >upgrading to TCPware V5.4-3 which disappeared without my intervention >(this gave a bad feeling then, and again, when I read some days/weeks >ago, that other users had strange errors with TCPware V5.4-3 and MX, too). I now also run the latest ECOs for TCPware like DRIVERS_V543P020... >In the meantime, I run a few UCX SMTP agent, too... And they still deliver the mails without problems so problem is in TCPware and obviously not on the remote site... Please help -- 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, 10 May 2000 08:07:40 -0500 Sender: schreiber@process.com Date: Wed, 10 May 2000 08:05:48 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E9DDF.039EDAA2.20@process.com> Subject: Re: MX problems since TCPware V5.4-3 eplan@kapsch.net writes: > >And they still deliver the mails without problems so problem is in TCPware >and obviously not on the remote site... > Peter, Have you logged an official call with support on this one? Engineering could use supports help in gathering details and information to help us try and solve the problem. Thanks - Jeff ================================================================================ Archive-Date: Wed, 10 May 2000 09:38:14 -0500 Return-Path: Subject: Re: MX problems since TCPware V5.4-3 From: eplan@kapsch.net Reply-To: Info-TCPware@process.com Message-ID: <391964ae$1@news.kapsch.co.at> Date: 10 May 2000 15:31:26 +0200 To: Info-TCPware@PROCESS.COM In article <009E9DDF.039EDAA2.20@process.com>, Jeff Schreiber writes: >eplan@kapsch.net writes: >>And they still deliver the mails without problems so problem is in TCPware >>and obviously not on the remote site... > >Peter, > Have you logged an official call with support on this one? Engineering > could use supports help in gathering details and information to help us > try and solve the problem. No. Support contract just ended. And a new one (with a new dist) will likely not happen (but nevertheless, I keep trying). And, I must admit, support of this group was far better than official support the last 2 years... Am I really the only one with such a (new since TCPware V5.4) problem ? -- 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, 10 May 2000 11:37:05 -0500 Sender: schreiber@process.com Date: Wed, 10 May 2000 11:35:12 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E9DFC.4456450E.23@process.com> Subject: Re: MX problems since TCPware V5.4-3 eplan@kapsch.net writes: > >Am I really the only one with such a (new since TCPware V5.4) problem ? > I've not been paying enough attention to this thread and the MX lists, but as far as I know you're the only one... I'll have to dig into it a little more. -Jeff ================================================================================ Archive-Date: Wed, 10 May 2000 11:41:54 -0500 Message-ID: <391982AF.68FB1481@bsco.com> Date: Wed, 10 May 2000 11:39:27 -0400 From: Alan Kemmerer Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: "Info-TCPware@process.com" Subject: Reloading hosts file Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit How can I force a reload of the hosts file with TCPWare 5.4 ? -- Alan J. Kemmerer - alan.kemmerer@bsco.com ================================================================================ Archive-Date: Wed, 10 May 2000 11:47:06 -0500 Message-ID: <391983F7.3026C779@PROCESS.COM> Date: Wed, 10 May 2000 11:44:55 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: FW: Reloading hosts file Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > How can I force a reload of the hosts file with TCPWare 5.4 ? > $ NETCU STOP/DNS $ @TCPWARE:START_RESOLVER DETACH Regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Wed, 10 May 2000 11:48:40 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860251A60B@lespaul.process.com> From: Matt Brightman Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Reloading hosts file Date: Wed, 10 May 2000 11:46:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Alan, The TCPWARE:HOSTS. file get reloaded every 10-15 minutes automatically (I forget the exact time). If you need to force a reload immediately you can do the following: $ NETCU STOP/DNS $ @TCPWARE:STARTUP_RESOLVER DETACH Regards, -Matt Brightman Process Software Corporation > -----Original Message----- > From: Alan Kemmerer [mailto:alan.kemmerer@bsco.com] > Sent: Wednesday, May 10, 2000 11:39 AM > To: Info-TCPware@process.com > Subject: Reloading hosts file > > > > How can I force a reload of the hosts file with TCPWare 5.4 ? > > -- > Alan J. Kemmerer - alan.kemmerer@bsco.com > ================================================================================ Archive-Date: Fri, 12 May 2000 13:47:34 -0500 Date: Fri, 12 May 2000 12:45:33 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <009E9F98.6D63491E.1@goat.process.com> Subject: Re: MX problems since TCPware V5.4-3 eplan@kapsch.net writes: > >In article <38f05347$1@news.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >>This week, I had a lot mails hanging (mostly to .CH addresses) in my MX queue >>and wondered why. > [...] >Error seen with TCPDUMP is: > >Tcpdump: listening on IPA0: >00:03:49.752833 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 482163 >563:482165023(1460) ack 1527593 win 4096 (DF) >00:04:28.187311 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 >(1460) ack 1 win 4096 (DF) >00:05:06.621932 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 >(1460) ack 1 win 4096 (DF) Well, as you can see from this, weilenmann-01.access.ch.smtp is not responding, and MX keeps trying to make the connection. Why isn't that system responding? There's the problem..... >>In the meantime, I run a few UCX SMTP agent, too... > >And they still deliver the mails without problems so problem is in TCPware >and obviously not on the remote site... > That I don't know, but I find it odd that the other system isn't responding to our attempts to connect. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 12 May 2000 17:58:46 -0500 Return-Path: Message-ID: <391C62B6.30090E52@SMTP.DeltaTel.RU> Date: Fri, 12 May 2000 23:59:50 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: MX problems since TCPware V5.4-3 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi Peter! Can you provide NETCU SHO NET output? Did you use a secondary IP address for weilenmann-01.access.ch ? > Tcpdump: listening on IPA0: > 00:03:49.752833 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 482163 > 563:482165023(1460) ack 1527593 win 4096 (DF) > 00:04:28.187311 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 > (1460) ack 1 win 4096 (DF) > 00:05:06.621932 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 > (1460) ack 1 win 4096 (DF) > 00:05:45.056497 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 > (1460) ack 1 win 4096 (DF) > 00:06:23.491005 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 > (1460) ack 1 win 4096 (DF) > 00:07:01.928655 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 > (1460) ack 1 win 4096 (DF) > 00:07:40.380288 mars.kapsch.co.at.51388 > weilenmann-01.access.ch.smtp: . 0:1460 > (1460) ack 1 win 4096 (DF) > > and so on (if you want/need I'll get a complete mail dialog in TCPDUMP) > > >I remember, having problems with MX deliveries, the first week after > >upgrading to TCPware V5.4-3 which disappeared without my intervention > >(this gave a bad feeling then, and again, when I read some days/weeks > >ago, that other users had strange errors with TCPware V5.4-3 and MX, too). > > I now also run the latest ECOs for TCPware like DRIVERS_V543P020... > > >In the meantime, I run a few UCX SMTP agent, too... > > And they still deliver the mails without problems so problem is in TCPware > and obviously not on the remote site... > > Please help > > -- > 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 -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Mon, 15 May 2000 17:04:34 -0500 Return-Path: Message-ID: <392061CF.ED39D722@SMTP.DeltaTel.RU> Date: Tue, 16 May 2000 00:45:03 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Custom IP filter Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi ! I'm would like to get more information about of possible variants to write some kind of IP filters. For example I have two interface cards supported by the TCP/IP stacks. I'm need receive IP packet from one interface (called "inside"), performs some task, and send this packet to the second interface (called "outside"). Any oppinion about possible variants will be greatly appreciated. PS:May be I'll write FireWall wit NAT & PAT, websense like server? I dunno. -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Tue, 16 May 2000 06:26:16 -0500 Return-Path: Subject: Re: Competitive ?! It's true ? From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <3921134e$1@news.kapsch.co.at> Date: 16 May 2000 11:22:22 +0200 To: Info-TCPware@PROCESS.COM In article , "Ruslan R. Laishev" writes: >http://WWW.OpenVMS.Digital.COM/network/tcpip_grid.html DHCP Client is missing (nobody offers it, so far) PPP on VAX is missing (TCPware+Multinet offers them, TCPIP+UCX not) eSNMP System Management Agent(s) is missing (TCPIP offers it, the rest not) - just to name a few - besides this We choose TCPware (some time ago) because it offered a LOT of features more than UCX (ok, not TCPIP) and because the price was only 1/6 (!!!) of UCX. It is different now, though. And AFAIK, you don't need to buy the TCPware Media (just like with TCPIP). You can copy it from a friend or you can download it (and the manuals in PDF format) from the PSC server(s) - and this is not the case with COMPAQ. So, at least part of the comparision is not complete/correct. If you want to buy the TCPIP manuals you also have to pay many bucks (eg. QA-VHRAA-GZ ~$300 for the VAX Kit and QA-0LXAA-GZ ~$400 for the Alpha Kit, though the doc is the same for VAX and Alpha => inconsistency is everywhere) -- 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, 16 May 2000 06:55:21 -0500 From: "Martin Vorlaender" Reply-To: Info-TCPware@process.com To: Subject: RE: Competitive ?! It's true ? Date: Tue, 16 May 2000 12:54:57 +0200 Message-ID: <50726a98b1867337a67b8c1969e75546392128be@pdv-systeme.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <3921134e$1@news.kapsch.co.at> Peter LANGSTOEGER wrote: > "Ruslan R. Laishev" writes: > >http://WWW.OpenVMS.Digital.COM/network/tcpip_grid.html > > DHCP Client is missing (nobody offers it, so far) > PPP on VAX is missing (TCPware+Multinet offers them, TCPIP+UCX not) > eSNMP System Management Agent(s) is missing (TCPIP offers it, > the rest not) > - just to name a few - And: the info on TCPware/Multinet is not up-to-date: current versions are 5.4 and 4.2, respectively. Which means the NOs at "New DNS/BIND implementation (V8.1.2)" have turned into YESes. A few added rows where TCPIP v5 earns NOs (and at least TCPware has YESes - I guess Multinet has, too): - DHCP Safe Failover (OK, is yet a draft) - Dynamic DNS (DDNS) - Support for VMS/VAX 5.5 and VMS/Alpha 6.0, both up to 7.2-1 - Paired Network Interface Support (load balancing and failover) - Spam Prevention - IMAP4 Server - NFS over TCP - Kerberos v4 Oh BTW: TCPware and Multinet have had an "Industry-Standard & Reliable Kernel (proven kernel from UNIX)" from the beginning, I believe. This, IMHO, leaves TCPIP v5's advantages (aside from price) in the marketing sector: - Single point support - who cares - Ships with OS - who cares - Installation integrated with OS install - who cares - License in EIP - who cares - Media on condist - who cares - Industry Standard Management Commands - UNIX AND VMS style - What the hell do they mean by that? Besides: who cares cu, Martin P.S.: OK, I admit it: I'm biased towards PSC. I did like DEC's decision to dump the UCX kernel, but they haven't yet quite caught up with PSC. -- OpenVMS: | Martin Vorlaender VMS & WNT programmer When you KNOW | work: mv@pdv-systeme.de where you want | http://www.pdv-systeme.de/users/martinv/ to go today. | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 16 May 2000 07:39:36 -0500 Return-Path: Message-ID: <39211A75.92CF1F87@SMTP.DeltaTel.RU> Date: Tue, 16 May 2000 13:52:53 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Competitive ?! It's true ? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi ! I was confused by next sentence: Single point support: DEC - yes, PSC - no and more over (!!!) Industry-Standard & Reliable NEW Kernel (proven kernel from UNIX): - DEC - yes, PSC - no Industry Standard Management Commands - UNIX AND VMS style: DEC - yes,PSC - no What a hell? *ix - is "Reliable" ?! Ha-ha-ha. "Industry standard" - bullshit. Just I was puzzled by "partner's releationships" showed in this table. Peter LANGSTOEGER wrote: > > In article , "Ruslan R. Laishev" writes: > >http://WWW.OpenVMS.Digital.COM/network/tcpip_grid.html > > DHCP Client is missing (nobody offers it, so far) > PPP on VAX is missing (TCPware+Multinet offers them, TCPIP+UCX not) > eSNMP System Management Agent(s) is missing (TCPIP offers it, the rest not) > - just to name a few - > > besides this > We choose TCPware (some time ago) because it offered a LOT of features more > than UCX (ok, not TCPIP) and because the price was only 1/6 (!!!) of UCX. > It is different now, though. > > And AFAIK, you don't need to buy the TCPware Media (just like with TCPIP). > You can copy it from a friend or you can download it (and the manuals in > PDF format) from the PSC server(s) - and this is not the case with COMPAQ. > > So, at least part of the comparision is not complete/correct. > If you want to buy the TCPIP manuals you also have to pay many bucks (eg. > QA-VHRAA-GZ ~$300 for the VAX Kit and QA-0LXAA-GZ ~$400 for the Alpha Kit, > though the doc is the same for VAX and Alpha => inconsistency is everywhere) > > -- > 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: Tue, 16 May 2000 08:27:29 -0500 Sender: schreiber@process.com Date: Tue, 16 May 2000 08:25:21 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: info-multinet@process.com, schreiber@process.com Message-ID: <009EA298.BD39B55E.98@process.com> Subject: RE: Competitive ?! It's true ? "Martin Vorlaender" writes: > >And: the info on TCPware/Multinet is not up-to-date: current versions >are 5.4 and 4.2, respectively. Which means the NOs at "New DNS/BIND >implementation (V8.1.2)" have turned into YESes. > That's marketing for you... slip back a bit and compare your current with your competitors slightly less than current products! >- Paired Network Interface Support (load balancing and failover) This is being worked on for 4.3 >Oh BTW: TCPware and Multinet have had an "Industry-Standard & >Reliable Kernel (proven kernel from UNIX)" from the beginning, >I believe. Multinet is based on the BSD 4.3 kernel. According to Compaq, "Industry-Standard & Reliable" is specifically the 4.4 kernel. TCPware's kernel is proprietary, and in my opinion, a lot more stable the any BSD port. >This, IMHO, leaves TCPIP v5's advantages (aside from price) in >the marketing sector: >- Single point support - who cares I think Ruslan asked what this one was about... Basically it means if your having problems with your system, weither it be with the hardware or the network... you call the same phone number. >- Ships with OS - who cares >- Installation integrated with OS install - who cares >- License in EIP - who cares >- Media on condist - who cares Basically all the above are saying "Yea... we're from the same vendor as the OS". >- Industry Standard Management Commands - UNIX AND VMS style > - What the hell do they mean by that? Besides: who cares Basically they support both the unix switches on the commands, and the VMS ones. In other words, you can do 'whois -h' or 'whois /host='. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 16 May 2000 08:43:06 -0500 Return-Path: Subject: RE: Competitive ?! It's true ? From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <392140d2@news.kapsch.co.at> Date: 16 May 2000 14:36:34 +0200 To: Info-TCPware@PROCESS.COM In article <50726a98b1867337a67b8c1969e75546392128be@pdv-systeme.de>, Martin Vorlaender writes: >Peter LANGSTOEGER wrote: >> "Ruslan R. Laishev" writes: >> >http://WWW.OpenVMS.Digital.COM/network/tcpip_grid.html >> >> DHCP Client is missing (nobody offers it, so far) >> PPP on VAX is missing (TCPware+Multinet offers them, TCPIP+UCX not) >> eSNMP System Management Agent(s) is missing (TCPIP offers it, >> the rest not) >> - just to name a few - > >And: the info on TCPware/Multinet is not up-to-date: current versions >are 5.4 and 4.2, respectively. Which means the NOs at "New DNS/BIND >implementation (V8.1.2)" have turned into YESes. Yup. Who will fix the table, COMPAQ, PSC or we (as some kind of independant) ?? >A few added rows where TCPIP v5 earns NOs (and at least TCPware has >YESes - I guess Multinet has, too): >- DHCP Safe Failover (OK, is yet a draft) Can't really comment. But AFAIK, DHCP database was always cluster aware/ready with TCPware. So what is Safe Failover ? An RFC method to get the same functionality TCPware gave us for the last 5 years or so. >- Dynamic DNS (DDNS) DDNS is BIND V8.x >- Support for VMS/VAX 5.5 and VMS/Alpha 6.0, both up to 7.2-1 In your words: Who cares ? Certainly not me. V7.1 and up is it for me. >- Paired Network Interface Support (load balancing and failover) Can't comment. >- Spam Prevention Yup. But MX is so far still better and works with TCPware _and_ UCX/TCPIP. >- IMAP4 Server Yup >- NFS over TCP Is this NFS V3 ? I thought NFS V3 is missing in all VMS implementations, so far. >- Kerberos v4 Yup, Kerberos V5 aka DCE is. IPsec ? >Oh BTW: TCPware and Multinet have had an "Industry-Standard & >Reliable Kernel (proven kernel from UNIX)" from the beginning, >I believe. I think so, too, but I don't really know. >This, IMHO, leaves TCPIP v5's advantages (aside from price) in >the marketing sector: >- Single point support - who cares I care. But I think, this is marketing speak. I did a common TCPware management in my cluster just from day 1 by redefining TCPWARE logical to a search list, with a PSC one and 1 common KAPSCH one (and there is the placement of the hosts, networks, services, NFS config, and so on) >- Ships with OS - who cares I care. But nevertheless, I run TCPware on my servers and TCPIP/UCX on the rest. >- Installation integrated with OS install - who cares >- License in EIP - who cares Anyone who must pay the price of the system should care. Is EIP for free ? No. Is it cheaper to buy EIP or TCPIP/TCPware ? It depends. >- Media on condist - who cares I care. If I have to buy it extra or have to use a Internet access to get it, I would think, this company does not help it's customers. But it is a very small argument, though. >- Industry Standard Management Commands - UNIX AND VMS style > - What the hell do they mean by that? Besides: who cares Yup. >cu, > Martin > >P.S.: OK, I admit it: I'm biased towards PSC. I did like DEC's >decision to dump the UCX kernel, but they haven't yet quite caught >up with PSC. I second that. You might know, that I'm still fighting with TCPIP V5 problems and therefore run most of my systems still with UCX V4.2-4 which means I still have no V5 advantages and therefor TCPware is currently a LOT better than UCX for me. So, to make the story shorter. Someone should make a table with all arguments and let every customer decide, if an argument/point is worth for careing. The current table _is_ biased to COMPAQ (what surprise) -- 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, 16 May 2000 08:57:34 -0500 Date: Tue, 16 May 2000 22:26:26 +0930 From: Jeremy Begg Subject: Re: Competitive ?! It's true ? To: Info-MultiNet@process.com CC: Info-TCPware@process.com, schreiber@process.com Reply-To: Info-TCPware@process.com Message-ID: <39214579.ABF76E5C@vsm.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <009EA298.BD39B55E.98@process.com> Hi all, Here's my 2c worth ... > >- Single point support - who cares > > I think Ruslan asked what this one was about... Basically it means > if your having problems with your system, weither it be with the hardware > or the network... you call the same phone number. And it's not uncommon for the Compaq customer service center to answer calls about MultiNet in any case (in my experience). > >- Ships with OS - who cares > >- Installation integrated with OS install - who cares Having just installed UCX 5.0 on OpenVMS VAX V7.2 (brand new install) I can report that (a) the version on the O/S CD-ROM is superseded by the CONDIST, and (b) the OpenVMS VAX installation procedure certainly does not integrate the installation of TCP/IP Services for OpenVMS. OK, I know Compaq marketing doesn't know about VAXes but if they're going to be pedantic so can I :-) > >- License in EIP - who cares Actually a lot of people care about that one: for most customers the performance and features of UCX (TCPIPSFOVMS) will be adequate, so why spend money on something you already have? (Yes it's inferior but since when did that stop people using something?) > >- Industry Standard Management Commands - UNIX AND VMS style > > - What the hell do they mean by that? Besides: who cares > > Basically they support both the unix switches on the commands, and > the VMS ones. In other words, you can do 'whois -h' or 'whois /host='. I challenge any UNIX guru to manage a UCX site using "standard" UNIX commands :-) Jeremy ================================================================================ Archive-Date: Tue, 16 May 2000 09:13:39 -0500 From: "Martin Vorlaender" Reply-To: Info-TCPware@process.com To: Subject: RE: Competitive ?! It's true ? Date: Tue, 16 May 2000 15:13:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <392140d2@news.kapsch.co.at> Peter LANGSTOEGER wrote: > Martin Vorlaender writes: > >- DHCP Safe Failover (OK, is yet a draft) > > Can't really comment. > But AFAIK, DHCP database was always cluster aware/ready with TCPware. > So what is Safe Failover ? An RFC method to get the same functionality > TCPware gave us for the last 5 years or so. Here "failover" refers to the primary and any secondary DHCP servers. It inhibits the case that on the primary DHCP server failing, a secondary sends out leases - and the primary upon return doesn't know. > >- Support for VMS/VAX 5.5 and VMS/Alpha 6.0, both up to 7.2-1 > > In your words: Who cares ? Certainly not me. V7.1 and up is it for me. I know of lots of VMS/VAX 5.5 sites, as well as VMS/Alpha 6.2 sites, who can't upgrade (e.g. because of Oracle). > >- Paired Network Interface Support (load balancing and failover) > > Can't comment. Load balancing and failover of TCP/IP traffic over two ethernet cards. > >- Spam Prevention > > Yup. But MX is so far still better and works with TCPware > _and_ UCX/TCPIP. Agreed. > >- NFS over TCP > > Is this NFS V3 ? > I thought NFS V3 is missing in all VMS implementations, so far. It is. It's just what it says: NFS not using UDP, but TCP. > IPsec ? No idea. But TCPware/Multinet also have support for those RSA devices. > >This, IMHO, leaves TCPIP v5's advantages (aside from price) in > >the marketing sector: > >- Single point support - who cares > > I care. But I think, this is marketing speak. IMHO, all of these points are... > I did a common TCPware management in my cluster just from day 1 > by redefining TCPWARE logical to a search list, with a PSC > one and 1 common KAPSCH one (and there is the placement of the > hosts, networks, services, > NFS config, and so on) Oh, I thought they meant you don't have to deal with any third party support. cu, Martin -- | Martin Vorlaender VMS/WNT programmer Unix is user friendly. | work: mv@pdv-systeme.de It's just selective about | http://www.pdv-systeme/users/martinv/ who his friends are. | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 16 May 2000 10:06:38 -0500 Message-ID: <8B06C18242A6D211A53D00204840292A010F26C7@exch1.cup.edu> From: "Sabo, Eric" Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM, Info-MultiNet@process.com Subject: Multi-Net Version 4.2 Date: Tue, 16 May 2000 10:04:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello all, We are using Multi-Net Version 4.2. In our DNS records we are trying to address a server by three ip address, these are A records in our DNS. Is there a way to set prior to these? The server has a NIC in it which uses a load balance right now, but it has two more ip address that can be use in case of a failure. Thanks, Eric Sabo NT Administrator Computing Services Center California University of Pennsylvania ================================================================================ Archive-Date: Tue, 16 May 2000 10:12:55 -0500 From: "Martin Vorlaender" Reply-To: Info-TCPware@process.com To: Subject: RE: Multi-Net Version 4.2 Date: Tue, 16 May 2000 16:12:29 +0200 Message-ID: <09bf928e053a8de2133ca238b5a9c73f3921570b@pdv-systeme.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <8B06C18242A6D211A53D00204840292A010F26C7@exch1.cup.edu> Sabo, Eric wrote: > We are using Multi-Net Version 4.2. In our DNS records we are > trying to address a server by three ip address, these are A > records in our DNS. Is there a way to set prior to these? AFAIK, no. The DNS serves out all addresses in a round-robin fashion. > The server has a NIC in it which uses a load balance right now, > but it has two more ip address that can be use in case of a failure. In case of a failure of what? cu, Martin -- OpenVMS: | Martin Vorlaender VMS & WNT programmer When you KNOW | work: mv@pdv-systeme.de where you want | http://www.pdv-systeme.de/users/martinv/ to go today. | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 16 May 2000 10:26:56 -0500 Return-Path: Message-ID: <39215414.2B1EA6F1@SMTP.DeltaTel.RU> Date: Tue, 16 May 2000 17:58:44 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Competitive ?! It's true ? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: [...] > >This, IMHO, leaves TCPIP v5's advantages (aside from price) in > >the marketing sector: > >- Single point support - who cares > > I think Ruslan asked what this one was about... Basically it means > if your having problems with your system, weither it be with the hardware > or the network... you call the same phone number. Yes. In my case it's single E-mail. :-) -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom Inc, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Tue, 16 May 2000 10:59:43 -0500 Sender: schreiber@process.com Date: Tue, 16 May 2000 10:57:33 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: info-multinet@process.com, schreiber@process.com Message-ID: <009EA2AE.008CA0C2.10@process.com> Subject: RE: Competitive ?! It's true ? eplan@kapsch.net (Peter LANGSTOEGER) writes: > >Yup. Who will fix the table, COMPAQ, PSC or we (as some kind of independant) > It's COMPAQ's table, and I doubt we'll be able to get them to update it, but I'll leave that up to our Marketing folks to worry about :) >>A few added rows where TCPIP v5 earns NOs (and at least TCPware has >>YESes - I guess Multinet has, too): >>- DHCP Safe Failover (OK, is yet a draft) > >Can't really comment. >But AFAIK, DHCP database was always cluster aware/ready with TCPware. >So what is Safe Failover ? An RFC method to get the same functionality >TCPware gave us for the last 5 years or so. > Not really. It's something entirely different, and is a protocol between a primary and a secondary DHCP server to share information. If one goes down, the other can take over and handle the requests. It's TCP/IP based, so it doesn't require running on clusters, or even on a single OS. I had a minor battle with someone at DECUS, where they were pushing the benefits of VMS clustering, and I was trying to explain that it's not a VMS specific protocol, and that was why VMS wasn't mentioned in the Presentation. If people are interested we can explain more about the protocol. We've given a couple of talks about it at DECUS [San Diego and Vienna], and I've submitted it for LA-2000 as well. Those interested, I strongly encourage you to try and read the draft: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-06.txt >>- Dynamic DNS (DDNS) > >DDNS is BIND V8.x > I'm not sure if the original poster was referring to Dynamic DNS support in DNS, or if they were indicating DHCP's use of Dynamic DNS [which is what I took it to be]. > >>- NFS over TCP > >Is this NFS V3 ? >I thought NFS V3 is missing in all VMS implementations, so far. > NFS by default is over UDP. This refers to being able to run NFS over TCP as well. > >>- Media on condist - who cares > >I care. If I have to buy it extra or have to use a Internet access to get it, >I would think, this company does not help it's customers. But it is a very >small argument, though. > Unfortunately I'm sure there isn't anything we can do to get our software on Compaq's condist. > >So, to make the story shorter. Someone should make a table with all arguments >and let every customer decide, if an argument/point is worth for careing. >The current table _is_ biased to COMPAQ (what surprise) > We've been working on coming up with our own table. I'm not sure what we have at the moment, but our Marketing folks might be able to voice in on that respect. -Jeff ================================================================================ Archive-Date: Wed, 17 May 2000 03:27:50 -0500 Return-Path: From: rankin@eql.caltech.edu (Pat Rankin) Reply-To: Info-TCPware@process.com Subject: Re: Competitive ?! It's true ? Date: 16 May 2000 23:48 PST Message-ID: <16MAY200023485233@eql.caltech.edu> To: Info-TCPware@PROCESS.COM In article <39211A75.92CF1F87@SMTP.DeltaTel.RU>,\ "Ruslan R. Laishev" writes... > I was confused by next sentence: > Single point support: DEC - yes, PSC - no That means that the tcp/ip vendor is the same as the operating system vendor, which implies that there will be less paperwork involved in support contracts, and also that there won't be any finger pointing at other vendors if your system crashes. That's not much of a reason to switch from MultiNet or TCPware to UCX, but it might perhaps be one for picking among them in the first place.... Pat Rankin, rankin@eql.caltech.edu ================================================================================ Archive-Date: Wed, 24 May 2000 17:02:54 -0500 Reply-To: Info-TCPware@process.com From: "Joe Gray" To: Subject: IBM MQSeries Date: Wed, 24 May 2000 15:50:26 -0500 Message-ID: <000001bfc5c1$b0fa0ac0$f13f366a@jgpc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Anyone out there use IBM MQSeries with Tcpware? I am trying to use between 2 vms 6.2/tcpware 5.3-2 vaxes. ================================================================================ Archive-Date: Wed, 24 May 2000 18:53:33 -0500 Return-Path: Reply-To: Info-TCPware@process.com From: "Jared Tugwell" Subject: Purveyor help please! Message-ID: Date: Wed, 24 May 2000 22:26:58 GMT To: Info-TCPware@PROCESS.COM Hello, I notice that these three newsgroups seem to be nothing but spam but I'll give this a shot anyway. Process Software has discontinued supporting Purveyor, their web server software. Does anyone have any knowledge of this product or know where there might be an email list I could subscribe to that could help? I am trying to enable SSL by installing a Server ID certificate. I appreciate anyone's help in advance. If it's not too much trouble would you please respond to me directly to my email account as well as this newsgroup? Please remove "SPAMZAPPER" from my address if you reply to author. My address is: jtugwel1@midsouth.rr.com. Thanks. -- Jared Tugwell ================================================================================ Archive-Date: Wed, 24 May 2000 19:46:35 -0500 Date: Wed, 24 May 2000 19:45:45 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V543P022 To: TCPware-Announce@PROCESS.COM Message-ID: <01JPSG9WEPTE004UGE@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_V543P022 Description: BGdriver system crash introduced in patch kit(DRIVE= RS_V543P020) Release date: 24-MAY-2000 =09Ranking: 1 Versions: 5.4-3, 5.3-3, 5.3-2 ftp://ftp.process.com/support/54_3/drivers_v543p022.zip To search the TCPware ECO database, please visit the following URL: http://www.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 2.2 for TCPware Version 5.4-3 2= 4-May-2000 Copyright =A9 1999-2000 Process Software Corporation This patch kit provides new versions of the following drivers for TCPware Version 5.4-3: =09BGDRIVER - Under certain circumstances, code introduced in =09 DRIVERS_V543P020 could cause an Unexpected System =09 Service Exception and crash the system when doing =09 NETCU SET BG_TCP commands. (D/E 6224, D/E 6243) This kit also includes the following changes from previous ECO ki= ts: For TCPware V5.4-3: DRIVERS_V543P020 ------------------ =09BGDRIVER - Add support for "privileged sockets" to allow beta 2 = of =09 the Apache server from Compaq to work. (D/E 5732) =09 - Add support for the DEC C values of the multicast =09 options to BGDRIVER (actual change was to IPDRIVER). =09 (D/E 5733) =09TCPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) =09UDPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) =09IPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) DRIVERS_V543P010 ------------------ =09TCPDRIVER - Changes made to the Outgoing Access Restrictions feat= ure =09 that corrects problems introduced in TCPware 5.4 and =09=09 DRIVERS_V533P050. (D/E 5350) For TCPware V5.3-3: DRIVERS_V533P050 ------------------ =09BGDRIVER - Modify behaviour of IO$_DEACCESS (D/E 2298) =09 - Modified to allow DCL/Perl scripts to work properly =09 under the Netscape FastTrack web server. (D/E 3509) =09 - Provide proper privilege checks under OpenVMS Alpha V= 7.2 =09 and higher. (D/E 5296) =09INETDRIVER - Correct the output of an extra for output from =09 REXEC (D/E 339) =09 - Provide proper privilege checks under OpenVMS Alpha =09 V7.2 and higher. (D/E 5296) =09IPDRIVER - Fix routine which derives largest MTU of all physical =09 interfaces. This is used by TCP to set the MSS =09 advertised at connection establishment. (D/E 2213) =09 - EWA twisted pair Ethernet controllers with the cable removed would hang TCPware during startup. This= problem =09 has been corrected. (D/E 2453) =09 - Provide proper privilege checks under OpenVMS Alpha =09 V7.2 and higher. (D/E 5296) =09NTDRIVER - Drop any received data when closing. (D/E 3330) =09 - Permanent NTA /w CLOSE_DASSGN cannot be=20 =09 deleted. (D/E 1537) =09 - Provide proper privilege checks under OpenVMS Alpha =09 V7.2 and higher. (D/E 5296) =09TCPDRIVER - Recognize SYN packets in successive connections when = old =09 connection is in TIME_WAIT (RLOGIN clients no longer = hang =09 on successive connections) (D/E 3872) =09 - Provide proper privilege checks under OpenVMS Alpha =09 V7.2 and higher. (D/E 5296) =09UDPDRIVER - Provide proper privilege checks under OpenVMS Alpha =09 V7.2 and higher. (D/E 5296) 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: Wed, 24 May 2000 21:55:58 -0500 Message-ID: <000a01bfc5ec$ebb4c670$e9de9318@ne.mediaone.net> From: "Evan D. Wells" Reply-To: Info-TCPware@process.com To: References: <000001bfc5c1$b0fa0ac0$f13f366a@jgpc> Subject: Re: IBM MQSeries Date: Wed, 24 May 2000 21:59:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I've done the installation on 7.2 clusters. What is your question? ----- Original Message ----- From: "Joe Gray" To: Sent: Wednesday, May 24, 2000 4:50 PM Subject: IBM MQSeries > Anyone out there use IBM MQSeries with Tcpware? I am trying to use between 2 > vms 6.2/tcpware 5.3-2 vaxes. > ================================================================================ Archive-Date: Thu, 25 May 2000 09:47:21 -0500 Return-Path: From: "Mike Duffy" Reply-To: Info-TCPware@process.com Subject: Re: (XP) Purveyor help please! Date: Thu, 25 May 2000 09:42:31 -0400 Message-ID: <8gjagm$3ee$1@bob.news.rcn.net> To: Info-TCPware@PROCESS.COM Hi Jared, Even though it's no longer a supported product, you may wish to use the info-multinet@process.com or info-tcpware@process.com lists. (But just one; the same people monitor both). Although off-topic, there are several people there who (I'll bet) will be willing to lend a hand. I am new enough to Process that I don't know much about Purveyor directly, so sorry, I can't be of direct help. Please understand that anything you receive that way will be strictly unsupported, unofficial, etc. Mike Duffy TCPware & MultiNet Engineering Process Software Corp. http://www.process.com Jared Tugwell wrote in message ... >Hello, I notice that these three newsgroups seem to be nothing but spam but >I'll give this a shot anyway. Process Software has discontinued supporting >Purveyor, their web server software. Does anyone have any knowledge of this >product or know where there might be an email list I could subscribe to that >could help? I am trying to enable SSL by installing a Server ID >certificate. I appreciate anyone's help in advance. If it's not too much >trouble would you please respond to me directly to my email account as well >as this newsgroup? Please remove "SPAMZAPPER" from my address if you reply >to author. My address is: jtugwel1@midsouth.rr.com. Thanks. >-- >Jared Tugwell > > > ================================================================================ Archive-Date: Thu, 25 May 2000 10:07:30 -0500 From: "Robert J Ellison" Reply-To: Info-TCPware@process.com Sender: "Robert J Ellison" To: Info-TCPware@process.com Message-ID: <052568EA.004D2884.00@mail2.us.hsbc.com> Date: Thu, 25 May 2000 10:08:01 -0400 Subject: Re: IBM MQSeries MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === Joe, We have been running MQ Series over TCPWare for about 4 months now. I was having problems with getting it set up, but once I got MQ PAC MC64, it explained how to do the set up. Attached is a copy of the PAC. I hope this helps. Rob Ellison HSBC Bank USA (See attached file: MQ Series Pac - mc64.htm) === MIME part removed : unknown type === ================================================================================ Archive-Date: Fri, 26 May 2000 16:43:20 -0500 Date: Fri, 26 May 2000 16:42:38 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P070 To: TCPware-Announce@PROCESS.COM Message-ID: <01JPV2GK91UA0050RS@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_V543P070 Description: Added previously documented method of disabling unix style syntax Release date: 26-MAY-2000 Ranking: 3 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p070.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 7.0) for TCPware version 5.4-3 22-May-2000 Copyright (c) 2000, by Process Software Corporation This VMSinstallable saveset provides a new versions of FTP_CONTROL.COM, FTP_LISTENER.EXE, and FTP_SERVER.EXE for TCPware for OpenVMS. TCPWare V5.4-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made in this kit: FTP_SERVER.EXE - There was a discrepency between the documentation and the code on how to disable Unix syntax in the FTP server. The documentation specified the logical TCPWARE_FTP_DISALLOW_UNIX_STYLE and the code checked for TCPWARE_FTPD_NOUNIX_SYNTAX. The code has been modified to check for both logicals. Note that the FTP server startup procedure defines TCPWARE_FTP_DISALLOW_UNIX_STYLE to TRUE if it is not already defined. If you want UNIX style directories to be enabled you must define TCPWARE_FTP_DISALLOW_UNIX_STYLE to FALSE. This can be done at either the system or user level. (DE 6219) The following changes from previous kits also in this kit: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) 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. - Correct a problem with FTP_V543P030 that could cause the TCPware_FTP process to consume channels. 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) - When the logical TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC is defined to TRUE files with variable length records and carriage return carriage control will NOT have a new line character inserted after each line when the file is transfered in image (binary) mode. This logical is now defined to be TRUE by default in FTPSERVER_DTP.COM, returning to the behavior present in TCPWare 5.3 (DE 5709) - Correct a problem that can occur when deleting files on a VAX from an NT system where the error "%LIB-F-INVSTRDES, invalid string descriptor" could occur. (DE 5722) - Correct a problem when TCPWARE_FTP__ROOT is defined to be disk:[dir.] /translation=conceal that would cause the user to be denied access to directories that previous versions of FTP did not deny access to. (DE5670) - Correct a problem with deleting wildcarded files in Unix mode. (DE 5734) - Correct a problem with displaying the directory in the 150 reply message in Unix mode. (DE 5736) - Correct a problem with the /IMAGE=size qualifier on the target file of a PUT command. (DE 6055) - Correct a problem with recognizing that TCPWARE_FTP__ROOT being defined as * means no restrictions. (DE 6058) - Allow /IMAGE=size to write out files with fixed length records of other than 512 bytes (DE 6055) After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Sat, 27 May 2000 15:24:36 -0500 Return-Path: From: Greg Reply-To: Info-TCPware@process.com Subject: how can i create an internet connection.... Date: Sat, 27 May 2000 14:17:30 -0500 Message-ID: <39301F4A.DE9607B6@cc.umanitoba.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM I have two computers, one running windows 98 with a dail in connection to the internent, the other is running windows for workgroups 3.11 . They are both connected via eithernet cards. I have installed tcp/ip protocol on both adapters. From here, what steps do I take to hook the wfw 3.11 system to the internet. Also, any tips on filling out the IP address and DNS feilds? (ect) I am not quite sure how they work, although I have an idea. -thanx, greg ================================================================================ Archive-Date: Tue, 30 May 2000 20:19:38 -0400 Return-Path: Subject: Re: MX problems since TCPware V5.4-3 From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <39345195@news.kapsch.co.at> Date: 31 May 2000 01:41:09 +0200 To: Info-TCPware@PROCESS.COM In article <009E9DFC.4456450E.23@process.com>, Jeff Schreiber writes: >eplan@kapsch.net writes: >>Am I really the only one with such a (new since TCPware V5.4) problem ? > > I've not been paying enough attention to this thread and the MX lists, > but as far as I know you're the only one... I'll have to dig into it a > little more. Ok. here some excerpts: (Incomplete ?) list of Domains so far involved: ACCESS.CH ASCOM.CH BUERKI.COM (=COSMOSYS.CH) BUHLERGROUP.COM (=BUHLER.CH) CASTOR.UNIT.NET (=SUNRISE.CH) CIBASC.COM (1st and 2nd mailserver in CH, 3rd in US) MIGROSBANK.CH SIEMENS.CH which when you translate the domains relate all to something in switzerland. This very surprising/annoying and surely more than a coincidence. That (and UCX delivers the mails without problems) is why I can't follow the argument, that the problem is on the "remote side". And so far every (of the few traced) SMTP dialog looks like this => SYN SEQ <= SYN ACK => ACK <= 220 => EHLO <= 250 => MAIL FROM: <= 250 (sender ok) => RCPT TO: <= 250 (recipient ok) => DATA <= 354 Enter mail, ... => 76 Byte => 1460 Byte <= ACK => 1460 Byte => 1460 Byte => 1460 Byte => 1460 Byte => 1460 Byte => 1460 Byte ...[10min later] => RST which is the "device timeout" already mentioned. I'm still clueless... Ok. Not really. I've two ideas: 1) Try again with TCPware DRIVERS_V543P022 installed (020 is now installed) 2) Try NETLIB/TCPware (instead of NETLIB/UCX+TCPware's UCX compatibility) But I don't expect any changes. And my users get bored by the DSN Delay notifications (until I see the entry and manually move them to the UCX agent) -Peter PS: Sniffer Dumps are available on request but I won't post them here. -- 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, 30 May 2000 20:31:01 -0400 Date: Tue, 30 May 2000 19:30:29 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000530193029.202000c0@goatley.com> Subject: Re: MX problems since TCPware V5.4-3 eplan@kapsch.net (Peter LANGSTOEGER) writes: > >which when you translate the domains relate all to something in switzerland. >This very surprising/annoying and surely more than a coincidence. >That (and UCX delivers the mails without problems) is why I can't follow the >argument, that the problem is on the "remote side". > That's fine, except for this: >And so far every (of the few traced) SMTP dialog looks like this [...] ><= 354 Enter mail, ... >=> 76 Byte >=> 1460 Byte ><= ACK >=> 1460 Byte >=> 1460 Byte >=> 1460 Byte >=> 1460 Byte Why isn't the other side ever ACKing any more? Why does it work with UCX? Mysteries to me.... Now, if we saw the ACK and we never sent any more data, I'd agree that it's the TCPware side, but.... What does a TCPDUMP with UCX show? Maybe smaller packets are being sent out (and acked) for some reason? Maybe there's something wrong with the MTU Discovery for those nodes. Try disabling that and see what happens (NETCU START/TCP/NOPATH_MTU_DISCOVERY). >which is the "device timeout" already mentioned. I'm still clueless... >Ok. Not really. I've two ideas: > >1) Try again with TCPware DRIVERS_V543P022 installed (020 is now installed) Shouldn't change anything. >2) Try NETLIB/TCPware (instead of NETLIB/UCX+TCPware's UCX compatibility) > Won't change anything, as it's the same thing. NETLIB/TCPware also uses the BG interface. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 30 May 2000 20:33:44 -0400 Date: Tue, 30 May 2000 19:33:17 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000530193317.202000c0@goatley.com> Subject: Re: MX problems since TCPware V5.4-3 Hunter Goatley writes: > >What does a TCPDUMP with UCX show? Maybe smaller packets are being >sent out (and acked) for some reason? Maybe there's something wrong >with the MTU Discovery for those nodes. Try disabling that and see >what happens (NETCU START/TCP/NOPATH_MTU_DISCOVERY). > I don't remember what UCX you're using, but UCX prior to V5.x did not support Path MTU, so that could very well explain what's happening. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 30 May 2000 20:43:44 -0400 Return-Path: Subject: Re: MX problems since TCPware V5.4-3 From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <39345fb2$1@news.kapsch.co.at> Date: 31 May 2000 02:41:22 +0200 To: Info-TCPware@process.com In article <000530193317.202000c0@goatley.com>, Hunter Goatley writes: >Hunter Goatley writes: >> >>What does a TCPDUMP with UCX show? Maybe smaller packets are being >>sent out (and acked) for some reason? Maybe there's something wrong >>with the MTU Discovery for those nodes. Try disabling that and see >>what happens (NETCU START/TCP/NOPATH_MTU_DISCOVERY). >> >I don't remember what UCX you're using, but UCX prior to V5.x did not >support Path MTU, so that could very well explain what's happening. V4.2 ECO 4. Ok, if PATH_MTU is the problem (which I'll check), was it introduced with V5.4-3 ? -- 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, 30 May 2000 20:48:40 -0400 Sender: goatley@triton.process.com Return-Path: Date: Tue, 30 May 2000 19:47:28 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000530194728.202000c0@goatley.com> Subject: Re: MX problems since TCPware V5.4-3 eplan@kapsch.net (Peter LANGSTOEGER) writes: > >Ok, if PATH_MTU is the problem (which I'll check), was it introduced with >V5.4-3 ? > No, it's been around a while. But a broken router was added between you and .CH around the same time you upgraded. It's a guess, but it matches what you're seeing.... Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 30 May 2000 20:50:25 -0400 Date: Tue, 30 May 2000 19:49:55 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000530194955.202000c0@goatley.com> Subject: Re: MX problems since TCPware V5.4-3 Hunter Goatley writes: > >No, it's been around a while. But a broken router was added between -----------------------------------^ That should have said "But *maybe* a broken router...." Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 31 May 2000 13:06:02 -0400 Return-Path: Message-ID: <3935415B.DFC2B61E@SMTP.DeltaTel.RU> Date: Wed, 31 May 2000 20:44:11 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: BINDIG an UDP socket (DEC TCPIP & PSC MULTINET/TCPWARE) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@process.com Hi There! I have an application which binding several DGRAM-sockets to different secondary IP addreses. I found a difference in behaviour when binding a socket: 1) I bind 0.0.0.0:1645 socket - Ok. 2) I bind 172.16.0.45:1645 socket - PSC MULTINET/TCPWARE - Ok. DEC TCPIP - SS$_DUPLNAM. What is solution? What the misbehaving is right? Checked under/with: TCPWare TCP - 5.3-3,5.4-3, Multinet,4.x - VMS/Alpha 7.1-1h1,7.2-1 DEC TCPIP 5.0a (w/o ECOs) - VMS/Alpha 7.2-1. -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom Inc, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 31 May 2000 16:08:49 -0400 Return-Path: From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: List of the interfaces Message-ID: Date: Wed, 31 May 2000 23:55:59 +0400 To: Info-TCPware@PROCESS.COM Hi All! I looking for an universal way to find "first main/physical" interface IP address under TCPWare/Multinet/UCX from C program. Is there who can help by advise ? TIA. -- + C U, SysMan at DLS ...................................................+ http://www.radiusvms.com | Cel: +7 (901) 971-3222 http://www.levitte.org/~rlaishev | Fax: +7 (812) 115-1035 + Flying by Su-27........................................ Frying on VMS +