Archive-Date: Sun, 1 Oct 2000 02:41:44 -0400 Return-Path: From: moi_is_me Reply-To: Info-TCPware@process.com Subject: newbie - TcpWare routing question Date: Sun, 01 Oct 2000 06:26:14 GMT Message-ID: <8r6le4$4jb$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Hi, Re: TcpWare 5.4, on ALPHA, works ok except ... if i was to PING 207.25.71.25, my external PPPOE hub dials out, and i can ping if however, i was to PING www.cnn.com, TcpWare complains lib-e-keynotfou, key not found in tree if i attempt to telnet instead to www.cnn.com, i get tcpware-e-nosuchost, unknown host So basically, TcpWare is not passing on internet names, only dotted notation format ... what silly thing i have i forgot to configure and/or define ? thanks inadvance -Pierre Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Sun, 1 Oct 2000 03:52:59 -0400 Return-Path: From: LESLIE@209-16-45-102.insync.net (Jerry Leslie) Reply-To: Info-TCPware@process.com Subject: Re: newbie - TcpWare routing question Message-ID: <8OBB5.3328$R6.8911@insync> Date: Sun, 01 Oct 2000 07:34:28 GMT To: Info-TCPware@PROCESS.COM moi_is_me (moi_is_me@my-deja.com) wrote: : Hi, : : Re: TcpWare 5.4, on ALPHA, works ok except ... : : if i was to PING 207.25.71.25, my external PPPOE hub : dials out, and i can ping : : if however, i was to PING www.cnn.com, TcpWare complains : lib-e-keynotfou, key not found in tree : : if i attempt to telnet instead to www.cnn.com, i get : tcpware-e-nosuchost, unknown host : : So basically, TcpWare is not passing on internet names, only : dotted notation format ... what silly thing i have i forgot : to configure and/or define ? : : : : thanks inadvance : : -Pierre : You need to configure TCPWare to use some DNS servers to resolve names to IP addresses. I've done this at a previous job, but don't recall the exact steps, but I did find a DejaNews article posted by Jeff Schreiber, Process Software LLC. According to that article, you can change "NAMED_SERVERS" by invoking the CNFNET DCL script: @CNFNET DNS which should change the TCPWARE_NAMESERVERS logical name. Then restart the TCPware DNS process: $ NETCU STOP/DNS $ @TCPWARE:STARTUP_RESOLVER DETACH If that doesn't configure the name servers, perhaps the TCPware FAQs will help: http://www.support.process.com/tcpware_faqs.html TCPware FAQs --Jerry Leslie leslie@209-16-45-97.insync.net leslie@209-16-45-102.insync.net is invalid (my opinions are strictly my own) ================================================================================ Archive-Date: Mon, 2 Oct 2000 06:53:00 -0400 Message-ID: <03D308C87334D311B252009027855AC77019CC@THUMPER> From: "Cruse, Trevor M." Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: Changing IP address of a server in DNS Date: Mon, 2 Oct 2000 06:41:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello All, We are running TCPware v5.4-3 with the latest patches. We are running DNS on one of our servers, with a file called SYS$COMMON:[TCPWARE.NAMED]NAMED.HOSTS that holds the names of our hosts as you expect. We recently implemented dynamic DNS updates from DNS, and after some hassles we got it to work. This weekend we needed to change the IP address of one of our servers. This is when we noticed that there is now another file called SYS$SYSROOT:[TCPWARE.NAMED]NAMED.HOSTS, which appears to be an updateable copy of the original NAMED.HOSTS. Anyway, we changed the IP address of the server in the original NAMED.HOSTS and re-loaded DNS. However the old IP address was still being picked up. The old IP address was still visible in the updateable NAMED.HOSTS. The server in question is on a totally different part of our WAN, so it's not DHCP that is putting the old IP address back in, so where is it coming from? We have just tried editing the updateable copy of NAMED.HOSTS to give the server its new IP address, and re-loaded DNS. Now we can no longer resolve the server at all - it fails. DNS is still loading okay - there are no error messages in tcpware:dns.log. Anyone have any ideas? How do we change the IP address of the server, and what's the relationship between the two copies of NAMED.HOSTS? Trevor Cruse IS Systems Manager Cooper-Avon Tyres Limited Melksham England (0044) 1225 357858 tmcruse@coopertire.com ================================================================================ Archive-Date: Mon, 2 Oct 2000 07:50:28 -0400 Date: Mon, 02 Oct 2000 12:55:50 +0100 From: David.Raymond@essential.co.uk Reply-To: Info-TCPware@process.com Subject: RE: Changing IP address of a server in DNS To: Info-TCPware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Trevor, DNS works with the first NAMED.HOSTS file it finds, looking in specific before common. Now you have one in specific, that is the one that will be used. If you amend the IP address in the specific copy and restart DNS then the change should be picked up. Regards David > -----Original Message----- > From: Cruse, Trevor M. [mailto:TMCruse@coopertire.com] > Sent: 02 October 2000 11:42 > To: Info-TCPware@process.com > Subject: Changing IP address of a server in DNS > > > Hello All, > > We are running TCPware v5.4-3 with the latest patches. We are > running DNS on > one of our servers, with a file called > SYS$COMMON:[TCPWARE.NAMED]NAMED.HOSTS that holds the names of > our hosts as > you expect. We recently implemented dynamic DNS updates from > DNS, and after > some hassles we got it to work. > > This weekend we needed to change the IP address of one of our > servers. This > is when we noticed that there is now another file called > SYS$SYSROOT:[TCPWARE.NAMED]NAMED.HOSTS, which appears to be > an updateable > copy of the original NAMED.HOSTS. Anyway, we changed the IP > address of the > server in the original NAMED.HOSTS and re-loaded DNS. However > the old IP > address was still being picked up. The old IP address was > still visible in > the updateable NAMED.HOSTS. The server in question is on a > totally different > part of our WAN, so it's not DHCP that is putting the old IP > address back > in, so where is it coming from? > > We have just tried editing the updateable copy of NAMED.HOSTS > to give the > server its new IP address, and re-loaded DNS. Now we can no > longer resolve > the server at all - it fails. DNS is still loading okay - > there are no error > messages in tcpware:dns.log. > > Anyone have any ideas? How do we change the IP address of > the server, and > what's the relationship between the two copies of NAMED.HOSTS? > > Trevor Cruse > IS Systems Manager > Cooper-Avon Tyres Limited > Melksham > England > > (0044) 1225 357858 > tmcruse@coopertire.com > > > > ================================================================================ Archive-Date: Mon, 2 Oct 2000 11:16:36 -0400 Return-Path: From: reli@mixmail.com Reply-To: Info-TCPware@process.com Subject: Rectification error :0j0 Super truco Linux 7405 Message-ID: <5FOB5.332204$LH4.1043744@telenews.teleline.es> Date: Sun, 01 Oct 2000 22:12:17 GMT To: Info-TCPware@PROCESS.COM Reenvio el mensaje ya que hubo un error al poner la web(falto la (L) de html os pido disculpas Para saber mas www.cambiaelchip.com/index2.html Si quieres tener como fondo de imagen un salvapantalla deves hacer lo siguiente: Antres de nada para una mejor visualizacion debes poner el fondo en Negro. Entra en xterm (kterm,konsole es indiferente ) desde las Xwindows(KDE) localiza tus salvapantallas con locate locate kss seguidamente elige el que mas te guste y ejecuta desde el mismo terminal que tengas abierto ej: kbouboule.kss -inroot & el salvapantallas se activara como imagen de fondo en esa ventana podra observar el PID (identificacion del proceso)asignado. Para detener la ejecucion del salvapantalla escribe en el terminal kill sustituya el PID number por la cifra real Seguro que os gustara Requisito aconsejado 128 Megas de Ram jocwlzyyjeeqsdeb ================================================================================ Archive-Date: Mon, 2 Oct 2000 11:44:19 -0400 Sender: schreiber@process.com Date: Mon, 2 Oct 2000 11:43:49 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009F0FEE.7E93FBF4.63@process.com> Subject: Re: newbie - TcpWare routing question LESLIE@209-16-45-102.insync.net (Jerry Leslie) writes: > >moi_is_me (moi_is_me@my-deja.com) wrote: >: if i was to PING 207.25.71.25, my external PPPOE hub >: dials out, and i can ping >: >: if however, i was to PING www.cnn.com, TcpWare complains >: lib-e-keynotfou, key not found in tree >: >: if i attempt to telnet instead to www.cnn.com, i get >: tcpware-e-nosuchost, unknown host > >You need to configure TCPWare to use some DNS servers to resolve >names to IP addresses. I've done this at a previous job, but don't >recall the exact steps, but I did find a DejaNews article posted by >Jeff Schreiber, Process Software LLC. > I love when people answer questions for me. And what I love more than that, is when they give me the credit! :) >According to that article, you can change "NAMED_SERVERS" by invoking >the CNFNET DCL script: > > @CNFNET DNS > >which should change the TCPWARE_NAMESERVERS logical name. > Exactly. Most likely you'll have to configure DNS. If you have a nameserver that you can point to, you'll have to know the IP address of that system. If you don't have one redily available, you can set yourself up with a caching server. I would do @tcpware:cnfnet DNS and answer the questions... then you should be all set. >Then restart the TCPware DNS process: > > $ NETCU STOP/DNS > $ @TCPWARE:STARTUP_RESOLVER DETACH > If a DNS resolver wasn't configured at all, you'd probably be safer restarting TCPware. Stopping and Starting the DNS process is a trick that gets you around a pinch, but it's not really recommended, as if someone makes a call that needs the resolver in the time that the process is gone, things could get a little confused... -Jeff -- Jeff Schreiber, Process Software LLC schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 2 Oct 2000 12:47:18 -0400 Return-Path: From: LESLIE@209-16-45-102.insync.net (Jerry Leslie) Reply-To: Info-TCPware@process.com Subject: Re: newbie - TcpWare routing question Message-ID: Date: Mon, 02 Oct 2000 16:21:04 GMT To: Info-TCPware@PROCESS.COM Jeff Schreiber (schreiber@process.com) wrote: : LESLIE@209-16-45-102.insync.net (Jerry Leslie) writes: : > : >You need to configure TCPWare to use some DNS servers to resolve : >names to IP addresses. I've done this at a previous job, but don't : >recall the exact steps, but I did find a DejaNews article posted by : >Jeff Schreiber, Process Software LLC. : > : : I love when people answer questions for me. And what I love more : than that, is when they give me the credit! :) : You're welcome. :-) --Jerry Leslie leslie@209-16-45-97.insync.net leslie@209-16-45-102.insync.net is invalid leslie@clio.rice.edu (my opinions are strictly my own) ================================================================================ Archive-Date: Tue, 3 Oct 2000 12:11:46 -0400 Sender: miller@process.com Date: Tue, 3 Oct 2000 12:11:11 -0400 From: Valerie Miller Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: miller@process.com Message-ID: <009F10BB.7B825BAE.22@process.com> Subject: RE: Changing IP address of a server in DNS For dynamic zones (ones with allow-update in the zone declaration in named.conf), the nameserver will re-write the zone file from its in-memory information periodically. You should not be editing these files by hand while the nameserver is running, or else your changes are likely to get lost, as you saw. You either need to make all changes to that zone dynamically, or shut down the nameserver, make your changes to the zone file by hand, then start up the nameserver again. Valerie Miller Process Software ================================================================================ Archive-Date: Tue, 3 Oct 2000 12:14:12 -0400 Date: Tue, 3 Oct 2000 11:13:06 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: MultiNet-Announce@lists.process.com, TCPware-Announce@lists.process.com Message-ID: <001003111306.202005c8@process.com> Subject: Process Software to Provide Development and Support for PMDF Products PRESS RELEASE For Information Contact: Donna Rogers Process Software, LLC (508) 879-6994 rogers@process.com Process Software to Provide Development and Support for PMDF Products Process to be Source for Innosoft PMDF Products Framingham, Massachusetts, October 2, 2000 - Process Software, a leader in networking solutions for OpenVMS, today announced an agreement with Innosoft International, Inc. designed to provide continued development and support for Innosoft PMDF(R) products. Innosoft was acquired by Sun Microsystems, Inc. earlier this year. In the agreement with Process, Innosoft will transition certain rights to development and responsibility for support of PMDF products on all platforms to Process Software. The goal of the relationship is to ensure that the PMDF customer base continues to receive the top quality service and product enhancements it has been accustomed to from Innosoft. "Process Software is uniquely positioned to understand both the business and technological needs of PMDF users", said Clyde Johnston, formerly Innosoft President and CEO. "The company's strong commitment to the OpenVMS market - demonstrated by the technological advances they continue to make to their TCPware and MultiNet TCP/IP products - combined with their firm dedication to customer support, will guarantee that this agreement serves the mission-critical business needs of our loyal PMDF customers." "This relationship assures that PMDF customers will continue to receive the best support and a full commitment to the product", said John Murgo, President and CEO of Process Software. "We are very excited about working with the PMDF customers and are committed to investing in the future of this product." Both companies are focused on implementing a seamless transition of responsibility for the support of Innosoft's PMDF products to Process Software. Effective immediately, customers should contact Process Software to purchase PMDF licenses or support. Current customers should continue to contact Innosoft for technical support until instructed otherwise. Process Software (www.process.com), in Framingham, Massachusetts, has been a leader in delivering premium networking software solutions since 1989. The company provides TCPware(R) and MultiNet(R), two TCP/IP software packages for Compaq's OpenVMS systems. Process Software is known for providing industry-leading support to its customers, including many Global 2000 and Fortune 1000 companies. Sun, Sun Microsystems, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. ================================================================================ Archive-Date: Tue, 3 Oct 2000 14:22:53 -0400 Return-Path: Message-ID: <39DA205C.7133B663@SMTP.DeltaTel.RU> Date: Tue, 03 Oct 2000 22:07:24 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Process Software to Provide Development and Support for PMDF Products Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@process.com Wow ! A good news ! Have PSC got plan to include Innosoft LDAP server in the TCPWare distribution kit ? Hunter Goatley wrote: > > PRESS RELEASE > > For Information Contact: > > Donna Rogers > Process Software, LLC > (508) 879-6994 > rogers@process.com > > Process Software to Provide Development and Support for PMDF Products > > Process to be Source for Innosoft PMDF Products > > Framingham, Massachusetts, October 2, 2000 - Process Software, a leader > in networking solutions for OpenVMS, today announced an agreement with > Innosoft International, Inc. designed to provide continued development > and support for Innosoft PMDF(R) products. Innosoft was acquired by Sun > Microsystems, Inc. earlier this year. In the agreement with Process, > Innosoft will transition certain rights to development and > responsibility for support of PMDF products on all platforms to Process > Software. The goal of the relationship is to ensure that the PMDF > customer base continues to receive the top quality service and product > enhancements it has been accustomed to from Innosoft. > > "Process Software is uniquely positioned to understand both the business > and technological needs of PMDF users", said Clyde Johnston, formerly > Innosoft President and CEO. "The company's strong commitment to the > OpenVMS market - demonstrated by the technological advances they > continue to make to their TCPware and MultiNet TCP/IP products - > combined with their firm dedication to customer support, will guarantee > that this agreement serves the mission-critical business needs of our > loyal PMDF customers." > > "This relationship assures that PMDF customers will continue to receive > the best support and a full commitment to the product", said John Murgo, > President and CEO of Process Software. "We are very excited about > working with the PMDF customers and are committed to investing in the > future of this product." > > Both companies are focused on implementing a seamless transition of > responsibility for the support of Innosoft's PMDF products to Process > Software. Effective immediately, customers should contact Process > Software to purchase PMDF licenses or support. Current customers should > continue to contact Innosoft for technical support until instructed > otherwise. > > Process Software (www.process.com), in Framingham, Massachusetts, has > been a leader in delivering premium networking software solutions since > 1989. The company provides TCPware(R) and MultiNet(R), two TCP/IP > software packages for Compaq's OpenVMS systems. Process Software is > known for providing industry-leading support to its customers, including > many Global 2000 and Fortune 1000 companies. > > Sun, Sun Microsystems, and the Sun logo are trademarks or registered > trademarks of Sun Microsystems, Inc. in the United States and other > countries. -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Wed, 4 Oct 2000 02:25:54 -0400 Date: Wed, 4 Oct 2000 1:25:26 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <001004012526.202006c8@process.com> Subject: Re: Process Software to Provide Development and Support for PMDF Products "Ruslan R. Laishev" writes: > >Wow ! A good news ! > > Have PSC got plan to include Innosoft LDAP server in the TCPWare distribution kit ? > It's a bit early in the process for us to say for sure what will happen, though I would guess that this will not happen (i.e, that the LDAP server will remain a separate product). Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Wed, 4 Oct 2000 03:26:39 -0400 Return-Path: Message-ID: <39DAD516.D5525EBF@SMTP.DeltaTel.RU> Date: Wed, 04 Oct 2000 10:58:30 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Process Software to Provide Development and Support for PMDFProducts Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM It's very pity. Hunter Goatley wrote: > > "Ruslan R. Laishev" writes: > > > >Wow ! A good news ! > > > > Have PSC got plan to include Innosoft LDAP server in the TCPWare distribution kit ? > > > It's a bit early in the process for us to say for sure what will > happen, though I would guess that this will not happen (i.e, that the > LDAP server will remain a separate product). > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www.goatley.com/hunter/ -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Wed, 4 Oct 2000 03:35:01 -0400 Date: Wed, 4 Oct 2000 2:34:35 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <001004023435.20200785@process.com> Subject: Re: Process Software to Provide Development and Support for PMDFProducts "Ruslan R. Laishev" writes: > >It's very pity. > The licensing terms may not even allow us to do that. As I said, it's a bit early to know the answers to questions like this. Bear with us, and let's see what happens..... Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Wed, 4 Oct 2000 06:54:27 -0400 Message-ID: <03D308C87334D311B252009027855AC77019D8@THUMPER> From: "Cruse, Trevor M." Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Info-TCPware Digest V100 #156 Date: Wed, 4 Oct 2000 06:42:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To Valerie at Process Software, Thanks, you comments on our problem with updating DNS has sorted out our problem. Trevor Cruse IS Systems Manager Cooper-Avon Tyres Limited -----Original Message----- From: Hunter Goatley -- Info-TCPware Owner [mailto:owner-Info-TCPware@process.com] Sent: 03 October 2000 23:00 To: Info-TCPware@process.com Subject: Info-TCPware Digest V100 #156 Info-TCPware Digest Tue, 3 Oct 2000 Volume 100 : Issue 156 Today's Topics: Changing IP address of a server in DNS Process Software to Provide Development and Support for PMDF Process Software to Provide Development and Support for PMDF Products Send digest submissions to: Info-TCPware@process.com Send add/unsubscribe requests to: Info-TCPware-request@process.com (send HELP for more information) Send problems about the list to: owner-info-tcpware@process.com Info-TCPware WWW home page: http://www.tcpware.process.com/ Info-TCPware FTP archives: ftp://ftp.tcpware.process.com/ Info-TCPware archives: http://www.tcpware.process.com/ ---------------------------------------------------------------------- Date: Tue, 3 Oct 2000 12:11:11 -0400 From: Valerie Miller Subject: Re: Changing IP address of a server in DNS Message-ID: <009F10BB.7B825BAE.22@process.com> For dynamic zones (ones with allow-update in the zone declaration in named.conf), the nameserver will re-write the zone file from its in-memory information periodically. You should not be editing these files by hand while the nameserver is running, or else your changes are likely to get lost, as you saw. You either need to make all changes to that zone dynamically, or shut down the nameserver, make your changes to the zone file by hand, then start up the nameserver again. Valerie Miller Process Software ------------------------------ Date: Tue, 03 Oct 2000 22:07:24 +0400 From: "Ruslan R. Laishev" Subject: Re: Process Software to Provide Development and Support for PMDF Message-ID: <39DA205C.7133B663@SMTP.DeltaTel.RU> Wow ! A good news ! Have PSC got plan to include Innosoft LDAP server in the TCPWare distribution kit ? Hunter Goatley wrote: > > PRESS RELEASE > > For Information Contact: > > Donna Rogers > Process Software, LLC > (508) 879-6994 > rogers@process.com > > Process Software to Provide Development and Support for PMDF Products > > Process to be Source for Innosoft PMDF Products > > Framingham, Massachusetts, October 2, 2000 - Process Software, a leader > in networking solutions for OpenVMS, today announced an agreement with > Innosoft International, Inc. designed to provide continued development > and support for Innosoft PMDF(R) products. Innosoft was acquired by Sun > Microsystems, Inc. earlier this year. In the agreement with Process, > Innosoft will transition certain rights to development and > responsibility for support of PMDF products on all platforms to Process > Software. The goal of the relationship is to ensure that the PMDF > customer base continues to receive the top quality service and product > enhancements it has been accustomed to from Innosoft. > > "Process Software is uniquely positioned to understand both the business > and technological needs of PMDF users", said Clyde Johnston, formerly > Innosoft President and CEO. "The company's strong commitment to the > OpenVMS market - demonstrated by the technological advances they > continue to make to their TCPware and MultiNet TCP/IP products - > combined with their firm dedication to customer support, will guarantee > that this agreement serves the mission-critical business needs of our > loyal PMDF customers." > > "This relationship assures that PMDF customers will continue to receive > the best support and a full commitment to the product", said John Murgo, > President and CEO of Process Software. "We are very excited about > working with the PMDF customers and are committed to investing in the > future of this product." > > Both companies are focused on implementing a seamless transition of > responsibility for the support of Innosoft's PMDF products to Process > Software. Effective immediately, customers should contact Process > Software to purchase PMDF licenses or support. Current customers should > continue to contact Innosoft for technical support until instructed > otherwise. > > Process Software (www.process.com), in Framingham, Massachusetts, has > been a leader in delivering premium networking software solutions since > 1989. The company provides TCPware(R) and MultiNet(R), two TCP/IP > software packages for Compaq's OpenVMS systems. Process Software is > known for providing industry-leading support to its customers, including > many Global 2000 and Fortune 1000 companies. > > Sun, Sun Microsystems, and the Sun logo are trademarks or registered > trademarks of Sun Microsystems, Inc. in the United States and other > countries. -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ------------------------------ Date: Tue, 3 Oct 2000 11:13:06 -0500 From: Hunter Goatley Subject: Process Software to Provide Development and Support for PMDF Products Message-ID: <001003111306.202005c8@process.com> PRESS RELEASE For Information Contact: Donna Rogers Process Software, LLC (508) 879-6994 rogers@process.com Process Software to Provide Development and Support for PMDF Products Process to be Source for Innosoft PMDF Products Framingham, Massachusetts, October 2, 2000 - Process Software, a leader in networking solutions for OpenVMS, today announced an agreement with Innosoft International, Inc. designed to provide continued development and support for Innosoft PMDF(R) products. Innosoft was acquired by Sun Microsystems, Inc. earlier this year. In the agreement with Process, Innosoft will transition certain rights to development and responsibility for support of PMDF products on all platforms to Process Software. The goal of the relationship is to ensure that the PMDF customer base continues to receive the top quality service and product enhancements it has been accustomed to from Innosoft. "Process Software is uniquely positioned to understand both the business and technological needs of PMDF users", said Clyde Johnston, formerly Innosoft President and CEO. "The company's strong commitment to the OpenVMS market - demonstrated by the technological advances they continue to make to their TCPware and MultiNet TCP/IP products - combined with their firm dedication to customer support, will guarantee that this agreement serves the mission-critical business needs of our loyal PMDF customers." "This relationship assures that PMDF customers will continue to receive the best support and a full commitment to the product", said John Murgo, President and CEO of Process Software. "We are very excited about working with the PMDF customers and are committed to investing in the future of this product." Both companies are focused on implementing a seamless transition of responsibility for the support of Innosoft's PMDF products to Process Software. Effective immediately, customers should contact Process Software to purchase PMDF licenses or support. Current customers should continue to contact Innosoft for technical support until instructed otherwise. Process Software (www.process.com), in Framingham, Massachusetts, has been a leader in delivering premium networking software solutions since 1989. The company provides TCPware(R) and MultiNet(R), two TCP/IP software packages for Compaq's OpenVMS systems. Process Software is known for providing industry-leading support to its customers, including many Global 2000 and Fortune 1000 companies. Sun, Sun Microsystems, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. ------------------------------ End of Info-TCPware Digest V100 #156 ************************************ ================================================================================ Archive-Date: Wed, 4 Oct 2000 14:51:59 -0400 Return-Path: Message-ID: <39DB7575.7547F9D8@SMTP.DeltaTel.RU> Date: Wed, 04 Oct 2000 22:22:45 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Process Software to Provide Development and Support forPMDFProducts Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hunter Goatley wrote: > > "Ruslan R. Laishev" writes: > > > >It's very pity. > > > The licensing terms may not even allow us to do that. As I said, it's > a bit early to know the answers to questions like this. Bear with us, > and let's see what happens..... :-) Thanks. I'll. Is hope also that someone will port a LDAP server while we waiting it from PSC. BTW, when a next version of the TCPWare will be released? SSH server, client..., improved SMTP ... ? > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www.goatley.com/hunter/ -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Thu, 5 Oct 2000 08:54:41 -0400 Message-ID: <03D308C87334D311B252009027855AC77B65D0@THUMPER> From: "Callard, Gavin A." Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: Problem configuring VMSMail to forward to Exchange Date: Thu, 5 Oct 2000 08:43:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi. We have an Exchange Server (Enterprise 5.5). It has IMC set up to receive mail and route it internally. The IMC config' is fine for our laptop users to connect and transfer mail using IMAP4 or POP3 and SMTP to send. No problems. We also have a few DEC Alpha's, running OpenVMS and using TCPWare. I need a hand configuring it so that VMS mail can send messages to the exchange server using SMTP. I don't want to make VMS Mail DNS aware; I just want it to forward all messages that are addressed with SMTP to the Exchange server. Note that the Exchange server is NOT receiving any SMTP connections; it's not getting that far (I've got high logging for that service and there is nothing showing up). At present I have set logicals for the following: "TCPWARE_SMTP_FORWARDER" = "thumper" (this is our exchange mail server, and it has a DNS entry) "TCPWARE_SMTP_FORWARD_REMOTE" = "TRUE" "TCPWARE_SMTP_POSTMASTER" = "SYSTEM" "TCPWARE_SMTP_QUEUE" = "TCPWARE_SMTP" "TCPWARE_SMTP_RETRY_INTERVAL" = "0 00:30:00.00" "TCPWARE_SMTP_RETURN_INTERVAL" = "4 00:00:00.00" "TCPWARE_SMTP_SEND_CLASS" = "16" I'm getting these NDRs every time: MICKEY>type ndr12.txt From: SMTP%"Postmaster@mickey.avontyres.co.uk." 4-OCT-2000 11:38:41.80 To: CC: Subj: Undeliverable Mail Return-Path: <> Date: Wed, 4 Oct 2000 11:38:41 GMT From: Postmaster@mickey.avontyres.co.uk. Subject: Undeliverable Mail To: Message-ID: Bad address -- Error -- Nameserver error: Resolver Error 0 (no error) Start of returned message Received: by mickey.avontyres.co.uk. for gcallard@coopertire.com; Wed, 4 Oct 2000 11:36:11 GMT Date: Wed, 4 Oct 2000 11:36:11 GMT From: system@mickey.avontyres.co.uk. To: gcallard@coopertire.com Message-Id: <001004113611.20410f1f@mickey.avontyres.co.uk.> Subject: test 12 test 12 End of returned message MICKEY> I'll try asking people at the exchange digest as well, see if anyone there can look at this from the opposite end. Any help would be much appreciated. Cheers, Gavin. Gavin Callard, B.Sc. Hon's; MCP. Information Systems Technician Microsoft is a registered trademark of Microsoft Corporation in the united States and other countries. e-mail: gcallard@coopertire.com (Internet) Callard, Gavin A. (Internal) gcallard@nadcom.org (Home) Phone: +44 (0) 1225 357 546 7546 (Internal) Information Systems Department, Cooper - Avon Tyres, Ltd. Melksham, Wiltshire, England. SN12 8AA "Things are more like they were than they are now" ================================================================================ Archive-Date: Thu, 5 Oct 2000 09:40:24 -0400 Message-ID: <002501c02ed1$3bb0a9d0$b404280a@jonp> From: "Jon Paine" Reply-To: Info-TCPware@process.com To: Subject: TCPWare can't find my adapter... Date: Thu, 5 Oct 2000 14:36:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi. I'm trying to install TCPWare 5.4 onto an AlphaServerGS 160. The adapter is a Compaq DE600/DE602 (thinks its the 602) / Fast Ethernet NC3131. The issue is that the TCPWare instal routine can't find the adapter in the system. Is this a supported machine and NIC...? Can I force the instal procedure into recognsing the card...? Is anyone else running on this HW configuration...? This one's got me a little flummoxed. Any help appreciated.... ================================================================================ Archive-Date: Thu, 5 Oct 2000 10:12:41 -0400 Message-ID: <67AB4F271D5DD3118A550090278A3F2C022C6380@ihs_mail_01.integralis.co.uk> From: Tremaine Callier Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPWare can't find my adapter... Date: Thu, 5 Oct 2000 15:10:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Jon, The DE602 is not officially supported but you should be able to get it to work by defining a logical for a supported interface, for example - $ define/sys/exec esa0 eia0 You should then be able to configure the device as ESA0 and have TCPware use the EIA0 device. There is already an enhancement request to have this device added in the next TCPware release. Tremaine -----Original Message----- From: Jon Paine [mailto:h2s04@bigfoot.com] Sent: 05 October 2000 14:36 To: Info-TCPware@process.com Subject: TCPWare can't find my adapter... Hi. I'm trying to install TCPWare 5.4 onto an AlphaServerGS 160. The adapter is a Compaq DE600/DE602 (thinks its the 602) / Fast Ethernet NC3131. The issue is that the TCPWare instal routine can't find the adapter in the system. Is this a supported machine and NIC...? Can I force the instal procedure into recognsing the card...? Is anyone else running on this HW configuration...? This one's got me a little flummoxed. Any help appreciated.... Integralis Theale House Brunel Road Theale, Reading RG7 4AQ +44 (0) 118 9306060 A member of the Articon-Integralis Group info@Integralis.com http://www.integralis.com DISCLAIMER Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error please notify the IT manager by telephone on +44 (0)118 930 6060 or via email to internal.security@integralis.com, including a copy of this message. Please then delete this email and destroy any copies of it. ================================================================================ Archive-Date: Sat, 7 Oct 2000 17:04:03 -0400 Date: Sat, 7 Oct 2000 16:03:36 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: GCallard@coopertire.com Message-ID: <001007160336.2020032f@goatley.com> Subject: RE: Problem configuring VMSMail to forward to Exchange "Callard, Gavin A." writes: > >nothing showing up). At present I have set logicals for the following: > >"TCPWARE_SMTP_FORWARDER" = "thumper" (this is our exchange mail server, >and it has a DNS entry) [...] >I'm getting these NDRs every time: [...] >Bad address -- >Error -- Nameserver error: Resolver Error 0 (no error) You might specifying the forwared as a fully-qualified domain name. I'm not sure that's what going on, but it's one thing I'd try. If that doesn't help, I'd recommend you contact our support group at . Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Sun, 8 Oct 2000 12:42:48 -0400 Return-Path: Message-ID: <39E09D6B.8056D15F@SMTP.DeltaTel.RU> Date: Sun, 08 Oct 2000 20:14:35 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: NAMED-XFER -> NL: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! How to disable these messages ? $ %%%%%%%%%%% OPCOM 8-OCT-2000 10:09:39.28 %%%%%%%%%%% Message from user SYSTEM on ANVIL named-xfer.exe;1: [xxx.xxx.0.xxx] not authoritative for jafe.com, SOA query got rcode 0, aa 0, ancount 0, aucount 12 -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Sun, 8 Oct 2000 13:00:39 -0400 Return-Path: Message-ID: <39E0A3F3.78962F9D@SMTP.DeltaTel.RU> Date: Sun, 08 Oct 2000 20:42:27 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: NAMED-XFER -> NL: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! I have a bunch of messages like follows, how I can to disable it ? $ %%%%%%%%%%% OPCOM 8-OCT-2000 10:09:39.28 %%%%%%%%%%% Message from user SYSTEM on ANVIL named-xfer.exe;1: [xxx.xxx.0.xxx] not authoritative for ZZtop.com, SOA query got rcode 0, aa 0, ancount 0, aucount 12 NAMED.CONF logging { channel opcom { syslog daemon; severity critical; print-category yes; print-severity yes; print-time yes; }; channel logfile { file "NL:"; severity info; print-category yes; print-severity yes; print-time yes; }; category error { logfile;}; category critical { logfile;}; category default { logfile;}; category update { logfile;}; category notify { logfile;}; category panic { logfile;}; category packetconfig { logfile;}; category ncache { logfile;}; category cname { logfile;}; category load { logfile;}; category maintenanceparser { logfile;}; category xfer-in { logfile;}; category security { logfile;}; category eventlib { logfile;}; category statisticsqueries { logfile;}; category xfer-out { logfile;}; category os { logfile;}; category insist { logfile;}; category dblame-servers { logfile;}; }; -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Mon, 9 Oct 2000 13:32:10 -0400 Sender: miller@process.com Date: Mon, 9 Oct 2000 13:31:24 -0400 From: Valerie Miller Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: miller@process.com Message-ID: <009F157D.AF19F721.101@process.com> Subject: RE: NAMED-XFER -> NL: > I have a bunch of messages like follows, how I can to disable it ? > >$ >%%%%%%%%%%% OPCOM 8-OCT-2000 10:09:39.28 %%%%%%%%%%% >Message from user SYSTEM on ANVIL >named-xfer.exe;1: [xxx.xxx.0.xxx] not authoritative for ZZtop.com, SOA query got rcode >0, aa 0, ancount 0, aucount 12 I don't think there is any way to disable the messages. Since they are put out by named-xfer, they are apparently not under the control of any of the logging categories. I think the only way to get rid of the opcom message is to fix the actual problem. If the given nameserver is supposed to be authoritative for the given zone, then figure out why it is saying it is not authoritative and fix the problem. If it is not supposed to be authoritative or if you can't fix the problem, then remove the given nameserver from the masters {} list. Valerie Miller Process Software ================================================================================ Archive-Date: Mon, 9 Oct 2000 15:22:30 -0400 Return-Path: Message-ID: <39E21668.5460B4D4@SMTP.DeltaTel.RU> Date: Mon, 09 Oct 2000 23:03:04 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: named-xfer Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi ! I have tried to get some more infromation by manualy start named-xfer: $ named:x :==$named-xfer $ namedx -d 1 -l zz.log -z zztop.com -f zztop.hosts -s 1 xxx.xxx.0.xxx $ $ typ zz.log %TYPE-W-SEARCHFAIL, error searching for SYS$COMMON:[TCPWARE.NAMED]ZZ.LOG; -RMS-E-FNF, file not found $ What is wrong ? -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Mon, 9 Oct 2000 15:43:47 -0400 Sender: miller@process.com Date: Mon, 9 Oct 2000 15:43:02 -0400 From: Valerie Miller Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: miller@process.com Message-ID: <009F1590.1279D6A8.72@process.com> Subject: RE: named-xfer > I have tried to get some more infromation by manualy start named-xfer: >$ named:x :==$named-xfer >$ namedx -d 1 -l zz.log -z zztop.com -f zztop.hosts -s 1 xxx.xxx.0.xxx >$ >$ typ zz.log >%TYPE-W-SEARCHFAIL, error searching for SYS$COMMON:[TCPWARE.NAMED]ZZ.LOG; >-RMS-E-FNF, file not found >$ > > What is wrong ? The actual file name used is the log file name you gave it with a suffix to make it unique, e.g. zz.log$000163 Also, you might want to increase the value of debug you are using. You'll get more information at level 2, 3, ... Valerie Miller Process Software ================================================================================ Archive-Date: Tue, 10 Oct 2000 06:18:41 -0400 Message-ID: <03D308C87334D311B252009027855AC77B65F6@THUMPER> From: "Callard, Gavin A." Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Problem configuring VMSMail to forward to Exchange Date: Tue, 10 Oct 2000 06:06:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks for this - I have tried changing the forwarder value to be fully qualified, but it's still producing the same results. I've mailed the support address now - see if they can throw some light on the situation. Gavin. -----Original Message----- From: Hunter Goatley [mailto:goathunter@PROCESS.COM] Sent: Saturday, October 07, 2000 10:04 PM To: Info-TCPware@process.com Cc: GCallard@coopertire.com Subject: RE: Problem configuring VMSMail to forward to Exchange "Callard, Gavin A." writes: > >nothing showing up). At present I have set logicals for the following: > >"TCPWARE_SMTP_FORWARDER" = "thumper" (this is our exchange mail server, >and it has a DNS entry) [...] >I'm getting these NDRs every time: [...] >Bad address -- >Error -- Nameserver error: Resolver Error 0 (no error) You might specifying the forwared as a fully-qualified domain name. I'm not sure that's what going on, but it's one thing I'd try. If that doesn't help, I'd recommend you contact our support group at . Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Tue, 10 Oct 2000 06:37:54 -0400 Message-ID: <67AB4F271D5DD3118A550090278A3F2C022C63A3@ihs_mail_01.integralis.co.uk> From: Tremaine Callier Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Problem configuring VMSMail to forward to Exchange Date: Tue, 10 Oct 2000 11:36:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I think you'll find you need to run a DNS server on the VMS box. I have experienced this problem, essentially the new SMTP (Multinet) server seems to require this. Doesn't matter what's in the DNS or how it's configured but no DNS server=no forwarding. I know it's not quite logical and is exactly what you're trying to avoid but... Tremaine -----Original Message----- From: Callard, Gavin A. [mailto:GCallard@coopertire.com] Sent: 10 October 2000 11:07 To: 'Info-TCPware@process.com' Subject: RE: Problem configuring VMSMail to forward to Exchange Thanks for this - I have tried changing the forwarder value to be fully qualified, but it's still producing the same results. I've mailed the support address now - see if they can throw some light on the situation. Gavin. -----Original Message----- From: Hunter Goatley [mailto:goathunter@PROCESS.COM] Sent: Saturday, October 07, 2000 10:04 PM To: Info-TCPware@process.com Cc: GCallard@coopertire.com Subject: RE: Problem configuring VMSMail to forward to Exchange "Callard, Gavin A." writes: > >nothing showing up). At present I have set logicals for the following: > >"TCPWARE_SMTP_FORWARDER" = "thumper" (this is our exchange mail server, >and it has a DNS entry) [...] >I'm getting these NDRs every time: [...] >Bad address -- >Error -- Nameserver error: Resolver Error 0 (no error) You might specifying the forwared as a fully-qualified domain name. I'm not sure that's what going on, but it's one thing I'd try. If that doesn't help, I'd recommend you contact our support group at . Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ Integralis Theale House Brunel Road Theale, Reading RG7 4AQ +44 (0) 118 9306060 A member of the Articon-Integralis Group info@Integralis.com http://www.integralis.com DISCLAIMER Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error please notify the IT manager by telephone on +44 (0)118 930 6060 or via email to internal.security@integralis.com, including a copy of this message. Please then delete this email and destroy any copies of it. ================================================================================ Archive-Date: Tue, 10 Oct 2000 06:44:13 -0400 Date: Tue, 10 Oct 2000 11:43:15 +0100 From: David.Raymond@essential.co.uk Reply-To: Info-TCPware@process.com Subject: RE: Problem configuring VMSMail to forward to Exchange To: Info-TCPware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 We've come across this DNS problem with SMTP as well. I don't think you actually need to have a DNS server running on the VMS box, but do need to have the TCPware config pointing at a valid DNS server somewhere - which clearly could be on the same box if you have not got one elsewhere. David > -----Original Message----- > From: Tremaine Callier [mailto:Tremaine.Callier@Integralis.com] > Sent: 10 October 2000 11:36 > To: 'Info-TCPware@process.com' > Subject: RE: Problem configuring VMSMail to forward to Exchange > > > I think you'll find you need to run a DNS server on the VMS > box. I have > experienced this problem, essentially the new SMTP (Multinet) > server seems > to require this. Doesn't matter what's in the DNS or how it's > configured but > no DNS server=no forwarding. > > I know it's not quite logical and is exactly what you're > trying to avoid > but... > > Tremaine > > -----Original Message----- > From: Callard, Gavin A. [mailto:GCallard@coopertire.com] > Sent: 10 October 2000 11:07 > To: 'Info-TCPware@process.com' > Subject: RE: Problem configuring VMSMail to forward to Exchange > > > Thanks for this - I have tried changing the forwarder value > to be fully > qualified, but it's still producing the same results. I've mailed the > support address now - see if they can throw some light on the > situation. > > Gavin. > > -----Original Message----- > From: Hunter Goatley [mailto:goathunter@PROCESS.COM] > Sent: Saturday, October 07, 2000 10:04 PM > To: Info-TCPware@process.com > Cc: GCallard@coopertire.com > Subject: RE: Problem configuring VMSMail > to forward > to Exchange > > "Callard, Gavin A." writes: > > > >nothing showing up). At present I have set > logicals for > the following: > > > >"TCPWARE_SMTP_FORWARDER" = "thumper" (this is our > exchange mail server, > >and it has a DNS entry) > > [...] > > >I'm getting these NDRs every time: > [...] > >Bad address -- > >Error -- Nameserver error: Resolver Error 0 (no error) > > You might specifying the forwared as a fully-qualified > domain name. > I'm not sure that's what going on, but it's one > thing I'd > try. > > If that doesn't help, I'd recommend you contact > our support > group at > . > > Hunter > ------ > Hunter Goatley, Process Software, > http://www.process.com/ > > http://www.goatley.com/hunter/ > > > Integralis > Theale House > Brunel Road > Theale, Reading > RG7 4AQ > +44 (0) 118 9306060 > > A member of the Articon-Integralis Group > > info@Integralis.com > http://www.integralis.com > > > DISCLAIMER > Any opinions expressed in this email are those of the > individual and not necessarily the Company. This email and > any files transmitted with it, including replies and > forwarded copies (which may contain alterations) subsequently > transmitted from the Company, are confidential and solely for > the use of the intended recipient. It may contain material > protected by attorney-client privilege. If you are not the > intended recipient or the person responsible for delivering > to the intended recipient, be advised that you have received > this email in error and that any use is strictly prohibited. > > If you have received this email in error please notify the IT > manager by telephone on +44 (0)118 930 6060 or via email to > internal.security@integralis.com, including a copy of this > message. Please then delete this email and destroy any copies of it. > ================================================================================ Archive-Date: Tue, 10 Oct 2000 06:45:59 -0400 Message-ID: <03D308C87334D311B252009027855AC77B65F7@THUMPER> From: "Callard, Gavin A." Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Problem configuring VMSMail to forward to Exchange Date: Tue, 10 Oct 2000 06:33:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" We are running DNS on the VMS box! When I wrote something about not wanting to have full on DNS I meant I don't want VMS mail to try and resolve internet address - I didn't word that very well did I? Oops! The VMS box is our organisations DNS server, and there is a backup on another server. It is also our DHCP server and we are using the Dynamic update feature. Why does it say "bad address"? I'm uncertain what the message is really trying to say. Gavin. -----Original Message----- From: Tremaine Callier [mailto:Tremaine.Callier@Integralis.com] Sent: Tuesday, October 10, 2000 11:36 AM To: 'Info-TCPware@process.com' Subject: RE: Problem configuring VMSMail to forward to Exchange I think you'll find you need to run a DNS server on the VMS box. I have experienced this problem, essentially the new SMTP (Multinet) server seems to require this. Doesn't matter what's in the DNS or how it's configured but no DNS server=no forwarding. I know it's not quite logical and is exactly what you're trying to avoid but... Tremaine -----Original Message----- From: Callard, Gavin A. [mailto:GCallard@coopertire.com] Sent: 10 October 2000 11:07 To: 'Info-TCPware@process.com' Subject: RE: Problem configuring VMSMail to forward to Exchange Thanks for this - I have tried changing the forwarder value to be fully qualified, but it's still producing the same results. I've mailed the support address now - see if they can throw some light on the situation. Gavin. -----Original Message----- From: Hunter Goatley [mailto:goathunter@PROCESS.COM] Sent: Saturday, October 07, 2000 10:04 PM To: Info-TCPware@process.com Cc: GCallard@coopertire.com Subject: RE: Problem configuring VMSMail to forward to Exchange "Callard, Gavin A." writes: > >nothing showing up). At present I have set logicals for the following: > >"TCPWARE_SMTP_FORWARDER" = "thumper" (this is our exchange mail server, >and it has a DNS entry) [...] >I'm getting these NDRs every time: [...] >Bad address -- >Error -- Nameserver error: Resolver Error 0 (no error) You might specifying the forwared as a fully-qualified domain name. I'm not sure that's what going on, but it's one thing I'd try. If that doesn't help, I'd recommend you contact our support group at . Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ Integralis Theale House Brunel Road Theale, Reading RG7 4AQ +44 (0) 118 9306060 A member of the Articon-Integralis Group info@Integralis.com http://www.integralis.com DISCLAIMER Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error please notify the IT manager by telephone on +44 (0)118 930 6060 or via email to internal.security@integralis.com, including a copy of this message. Please then delete this email and destroy any copies of it. ================================================================================ Archive-Date: Tue, 10 Oct 2000 06:49:24 -0400 Message-ID: <03D308C87334D311B252009027855AC77B65F8@THUMPER> From: "Callard, Gavin A." Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Problem configuring VMSMail to forward to Exchange Date: Tue, 10 Oct 2000 06:37:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I have these logicals going on: "TCPWARE_NAMED_ROOT" = "TCPWARE_ROOT:[TCPWARE.NAMED]" "TCPWARE_NAMED_SERVER_CONTROL" = "MBA247:" "TCPWARE_NAMESERVERS" [super] = "127.0.0.1" "TCPWARE_NAMESERVERS" [exec] = "127.0.0.1" being as the DNS is on the same server. If I log onto another server, the nameservers address points to the right address too. NSLookup at the VMS prompt works and can resolve for our exchange box. ???? -----Original Message----- From: David.Raymond@essential.co.uk [mailto:David.Raymond@essential.co.uk] Sent: Tuesday, October 10, 2000 11:43 AM To: Info-TCPware@process.com Subject: RE: Problem configuring VMSMail to forward to Exchange We've come across this DNS problem with SMTP as well. I don't think you actually need to have a DNS server running on the VMS box, but do need to have the TCPware config pointing at a valid DNS server somewhere - which clearly could be on the same box if you have not got one elsewhere. David > -----Original Message----- > From: Tremaine Callier [mailto:Tremaine.Callier@Integralis.com] > Sent: 10 October 2000 11:36 > To: 'Info-TCPware@process.com' > Subject: RE: Problem configuring VMSMail to forward to Exchange > > > I think you'll find you need to run a DNS server on the VMS > box. I have > experienced this problem, essentially the new SMTP (Multinet) > server seems > to require this. Doesn't matter what's in the DNS or how it's > configured but > no DNS server=no forwarding. > > I know it's not quite logical and is exactly what you're > trying to avoid > but... > > Tremaine > > -----Original Message----- > From: Callard, Gavin A. [mailto:GCallard@coopertire.com] > Sent: 10 October 2000 11:07 > To: 'Info-TCPware@process.com' > Subject: RE: Problem configuring VMSMail to forward to Exchange > > > Thanks for this - I have tried changing the forwarder value > to be fully > qualified, but it's still producing the same results. I've mailed the > support address now - see if they can throw some light on the > situation. > > Gavin. > > -----Original Message----- > From: Hunter Goatley [mailto:goathunter@PROCESS.COM] > Sent: Saturday, October 07, 2000 10:04 PM > To: Info-TCPware@process.com > Cc: GCallard@coopertire.com > Subject: RE: Problem configuring VMSMail > to forward > to Exchange > > "Callard, Gavin A." writes: > > > >nothing showing up). At present I have set > logicals for > the following: > > > >"TCPWARE_SMTP_FORWARDER" = "thumper" (this is our > exchange mail server, > >and it has a DNS entry) > > [...] > > >I'm getting these NDRs every time: > [...] > >Bad address -- > >Error -- Nameserver error: Resolver Error 0 (no error) > > You might specifying the forwared as a fully-qualified > domain name. > I'm not sure that's what going on, but it's one > thing I'd > try. > > If that doesn't help, I'd recommend you contact > our support > group at > . > > Hunter > ------ > Hunter Goatley, Process Software, > http://www.process.com/ > > http://www.goatley.com/hunter/ > > > Integralis > Theale House > Brunel Road > Theale, Reading > RG7 4AQ > +44 (0) 118 9306060 > > A member of the Articon-Integralis Group > > info@Integralis.com > http://www.integralis.com > > > DISCLAIMER > Any opinions expressed in this email are those of the > individual and not necessarily the Company. This email and > any files transmitted with it, including replies and > forwarded copies (which may contain alterations) subsequently > transmitted from the Company, are confidential and solely for > the use of the intended recipient. It may contain material > protected by attorney-client privilege. If you are not the > intended recipient or the person responsible for delivering > to the intended recipient, be advised that you have received > this email in error and that any use is strictly prohibited. > > If you have received this email in error please notify the IT > manager by telephone on +44 (0)118 930 6060 or via email to > internal.security@integralis.com, including a copy of this > message. Please then delete this email and destroy any copies of it. > ================================================================================ Archive-Date: Wed, 11 Oct 2000 15:39:52 -0400 Return-Path: Message-ID: <39E4BAA5.2971CF4A@SMTP.DeltaTel.RU> Date: Wed, 11 Oct 2000 23:08:21 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: NAMED.CONF & acl Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! What are covered by predefined ACL "localhost": 1) 127.0.0.1 ? 2) IP of the physical interface(s) ? 3) All physical and pseudo (PSD) interfaces ? TIA. -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Wed, 11 Oct 2000 16:07:55 -0400 Sender: schreiber@process.com Date: Wed, 11 Oct 2000 16:07:04 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009F1725.C2EEA3F1.141@process.com> Subject: RE: NAMED.CONF & acl "Ruslan R. Laishev" writes: > >Hi All! > What are covered by predefined ACL "localhost": > 1) 127.0.0.1 ? > 2) IP of the physical interface(s) ? > 3) All physical and pseudo (PSD) interfaces ? > Should be. All the IP addresses of all the interfaces on the system. -Jeff ================================================================================ Archive-Date: Thu, 12 Oct 2000 03:43:11 -0400 Return-Path: Message-ID: <39E5669A.9F4CF5B2@SMTP.DeltaTel.RU> Date: Thu, 12 Oct 2000 11:22:02 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: NAMED.CONF & acl Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > >Hi All! > > What are covered by predefined ACL "localhost": > > 1) 127.0.0.1 ? > > 2) IP of the physical interface(s) ? > > 3) All physical and pseudo (PSD) interfaces ? > > > > Should be. All the IP addresses of all the interfaces on the system. Thanks Jeff! -- Cheers. +------------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com ================================================================================ Archive-Date: Mon, 16 Oct 2000 09:19:08 -0400 Sender: goatley@triton.process.com Return-Path: Message-ID: <8A37FE7D529ED411983E00D0B75D01FC855F32@sirius.drmc.drhsi.org> From: David Collins Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: printing via lpr to lpd printer from OpenVMS Date: Wed, 11 Oct 2000 14:01:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" We noticed when setting up a print queue to print via lpr, that if the destination print device is unavailable when the job is submitted, it goes into a retained on error state, but the queue doesn't get paused or stalled. Also, the job won't automatically retry to print after a length of time. My question is, does anyone know how to make these jobs automatically retry to print? Thanks.. David C. Collins Jr. Network and Systems Analyst Danville Regional Medical Center ================================================================================ Archive-Date: Tue, 17 Oct 2000 07:37:51 -0400 Return-Path: From: "NTLWorld News" Reply-To: Info-TCPware@process.com Subject: TCPWare Internet Mail Message-ID: Date: Tue, 17 Oct 2000 12:34:10 +0100 To: Info-TCPware@PROCESS.COM I have a DEC Alpha running TCPWare on our NT network. I can send Internet-style e-mail to anyone on the network provided that the IP address of their domain mail server is present in the HOSTS. file. This is fine for our own employees as we only have 3 mail servers and thus 3 IP addresses to add to the hosts file. This isn't practical for general global e-mail as you would have to know and enter the IP address of each recipient in the HOSTS. file, obviously not the way to go! Anyone out there know how to set TCPWare up to achieve global e-mail usage? Many thanks, John Bennett ================================================================================ Archive-Date: Tue, 17 Oct 2000 09:07:44 -0400 Return-Path: Message-ID: <39EC45A7.78868AD6@SMTP.DeltaTel.RU> Date: Tue, 17 Oct 2000 16:27:19 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWare Internet Mail Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM You need to configure a DNS resolver (or server) on your host: $@tcpware:cnfnet DNS NTLWorld News wrote: > > I have a DEC Alpha running TCPWare on our NT network. I can send > Internet-style e-mail to anyone on the network provided that the IP address > of their domain mail server is present in the HOSTS. file. This is fine for > our own employees as we only have 3 mail servers and thus 3 IP addresses to > add to the hosts file. This isn't practical for general global e-mail as > you would have to know and enter the IP address of each recipient in the > HOSTS. file, obviously not the way to go! Anyone out there know how to set > TCPWare up to achieve global e-mail usage? Many thanks, John Bennett -- 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-1099 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Fri, 20 Oct 2000 11:44:16 -0400 Date: Fri, 20 Oct 2000 10:43:20 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-MultiNet@process.com CC: Info-TCPware@process.com, Info-PMDF@process.com Message-ID: <001020104320.202000c5@goatley.com> Subject: Administrivia: When posting to the list from NEWS.... As part of our anti-relay and anti-spam blocks, Process.com rejects mail from invalid domain names. This is a most effective way of blocking spam, as lots of spammers use invalid domain names. Unfortunately, some people posting to this list through Usenet try to avoid spam by munging their return address to something like: goathunter@process.comnospam While that means you won't get spam, it also means your NEWS posts to vmsnet.networks.tcp-ip.multinet, vmsnet.networks.tcp-ip.tcpware, and vmsnet.mail.pmdf will not make it through the gateway into their respecive mailing lists. If you intend to try to avoid spam by munging your address, a better method would be to munge the user portion of your address: goathunternospam@process.com That leaves the domain name alone, and allows your mail to pass into process.com. (I've posted this because a few responses through NEWS have not made it to the mailing lists in the past few days.) Thanks. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Mon, 23 Oct 2000 06:15:21 -0400 Message-ID: <03D308C87334D311B252009027855AC77B6693@THUMPER> From: "Callard, Gavin A." Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: Telnet and other things... Date: Mon, 23 Oct 2000 05:53:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, We're using TCPWare. We have some remote sites connecting using ISDN. The routers at both ends have been configured to drop the line if no interesting traffic goes over it. This used to work fine - until we moved across to TCPWare. Now, the Idle timeouts on the routers are being reset around every 2 min due to "interesting" traffic - we want this to stop! Is there some kind of keep alive value in TCPWare that could be doing this?? These sites only use Telnet. Any ideas? Thanks, Gavin. Gavin Callard, B.Sc. Hon's; MCP. Information Systems Technician Microsoft is a registered trademark of Microsoft Corporation in the united States and other countries. e-mail: gcallard@coopertire.com (Internet) Callard, Gavin A. (Internal) gcallard@nadcom.org (Home) Phone: +44 (0) 1225 357 546 7546 (Internal) Information Systems Department, Cooper - Avon Tyres, Ltd. Melksham, Wiltshire, England. SN12 8AA "Things are more like they were than they are now" ================================================================================ Archive-Date: Mon, 23 Oct 2000 06:45:29 -0400 Date: Mon, 23 Oct 2000 11:23:24 +0100 (BST) From: admin@bg-group.com Subject: Internet e-Mail address change To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <01JVOB0LHXXE8Y5DIB@mailhub.bg-group.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7BIT Message addressed to: steve.wakelin@bg-int.com Subject: Telnet and other things... The bg-int.com e-Mail domain is to be retired This users e-Mail address has changed to steve.wakelin@bg-group.com Please update your address books accordingly Your Original message has been forwarded to this recipient ------------------------------------------------------------------ Apologies for any inconvenience caused ================================================================================ Archive-Date: Mon, 23 Oct 2000 07:25:12 -0400 Date: Mon, 23 Oct 2000 11:58:23 +0100 (BST) From: admin@bg-group.com Subject: Internet e-Mail address change To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <01JVOC8YA7OI8Y5ELJ@mailhub.bg-group.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7BIT Message addressed to: nolan.m@bgep.co.uk Subject: Telnet and other things... The bgep.co.uk domain is to be removed from service This users e-Mail address has changed to mark.nolan@bg-group.com Please update your address books accordingly Your Original message has been forwarded to this recipient ------------------------------------------------------------------ Apologies for any inconvenience caused ================================================================================ Archive-Date: Mon, 23 Oct 2000 09:34:48 -0400 Date: Mon, 23 Oct 2000 8:34:10 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <001023083410.202000c5@goatley.com> Subject: RE: Telnet and other things... "Callard, Gavin A." writes: > >We're using TCPWare. We have some remote sites connecting using ISDN. The >routers at both ends have been configured to drop the line if no interesting >traffic goes over it. This used to work fine - until we moved across to >TCPWare. Now, the Idle timeouts on the routers are being reset around every >2 min due to "interesting" traffic - we want this to stop! Is there some >kind of keep alive value in TCPWare that could be doing this?? These sites >only use Telnet. Any ideas? > Yes, it's most likely KEEPALIVE that's keeping the lines up. You can disable that with: $ run tcpware:netcu NETCU> show service telnet stream/full NETCU> modify service telnet stream/options=nokeepalive You can put the MODIFY command in TCPWARE:ROUTING.COM to execute it each time your system starts. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Mon, 23 Oct 2000 09:39:43 -0400 Message-ID: <03D308C87334D311B252009027855AC77B669A@THUMPER> From: "Callard, Gavin A." Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Telnet and other things... Date: Mon, 23 Oct 2000 09:25:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Great, thanks - I will give that a try. Cheers, Gavin. -----Original Message----- From: Hunter Goatley [mailto:goathunter@PROCESS.COM] Sent: Monday, October 23, 2000 2:34 PM To: Info-TCPware@process.com Subject: RE: Telnet and other things... "Callard, Gavin A." writes: > >We're using TCPWare. We have some remote sites connecting using ISDN. The >routers at both ends have been configured to drop the line if no interesting >traffic goes over it. This used to work fine - until we moved across to >TCPWare. Now, the Idle timeouts on the routers are being reset around every >2 min due to "interesting" traffic - we want this to stop! Is there some >kind of keep alive value in TCPWare that could be doing this?? These sites >only use Telnet. Any ideas? > Yes, it's most likely KEEPALIVE that's keeping the lines up. You can disable that with: $ run tcpware:netcu NETCU> show service telnet stream/full NETCU> modify service telnet stream/options=nokeepalive You can put the MODIFY command in TCPWARE:ROUTING.COM to execute it each time your system starts. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Wed, 25 Oct 2000 10:21:00 -0400 Return-Path: Subject: Re: TCP-IP-protocol for Win 3.11 ??? Where ??? From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <39f6e947$1@news.kapsch.co.at> Date: 25 Oct 2000 16:08:07 +0200 To: Info-TCPware@PROCESS.COM In article <8QAJ5.336$Yq.9327@afrodite.telenet-ops.be>, "Daniel Ronsmans" writes: >Where can I find TCP-IP protocol for Win 3.11 ?? Not on [Open]VMS (where this newsgroup [hierarchy] is for). Ask M$ (http://www.microsoft.com) They used to offer such a beast for free, many many years ago... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 25 Oct 2000 10:31:59 -0400 Return-Path: Subject: Bug in TCPWARE:RCMD_CONTROL.COM From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <39f6ee49$1@news.kapsch.co.at> Date: 25 Oct 2000 16:29:29 +0200 To: Info-TCPware@process.com There is a (simply fixable) bug in TCPWARE:RCMD_CONTROL.COM which prevents the (very uncommon) $ SET HOST/RLOGIN The bug is a missing apostrophe (in V5.4 = edit level 32 in line 435) $ DEFINE/SYSTEM/EXEC/NOLOG OPENVMS$RLOGIN 'RLOGIN_EXE_FILE ^^^ jfi -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 25 Oct 2000 10:44:42 -0400 Date: Wed, 25 Oct 2000 9:44:04 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <001025094404.202000c5@goatley.com> Subject: RE: Bug in TCPWARE:RCMD_CONTROL.COM eplan@kapsch.net (Peter LANGSTOEGER) writes: > >There is a (simply fixable) bug in TCPWARE:RCMD_CONTROL.COM which prevents >the (very uncommon) > Thanks for the info! Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Thu, 26 Oct 2000 17:22:11 -0400 Return-Path: Subject: V72_MGMTAGENTS and TCPware From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <39f89ec9$1@news.kapsch.co.at> Date: 26 Oct 2000 23:14:49 +0200 To: Info-TCPware@PROCESS.COM After finding out, that the (long awaited) MGMTAGENTS are not compatbile with TCPware, we heard that "they will be supported soon". Is there any progress ? Is there already a TCPware SNMP agent which supports Q's V72_MGMTAGENTS as eSNMP subagents ? If not, when expected ? TCPware has still A LOT more features than Q's TCP/IPs and more still to come (SSH, SYSLOGD, future VMS extauth support, ...) hopefully. [e]SNMP seems to be so far the only disadvantage of TCPware (no UCX compatibility in this area ?) TIA PS: The V7x_MGMTAGENTS are not an example of good VMS programming. They are not cluster aware (eg. installed in SYS$SPECIFIC) -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Fri, 27 Oct 2000 05:01:15 -0400 Message-ID: <03D308C87334D311B252009027855AC7F2CD18@THUMPER> From: "Cruse, Trevor M." Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: Date: Fri, 27 Oct 2000 04:47:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Re: adding the command 'modify service telnet stream/options=nokeepalive' to tcpware:routing.com. If you do this it causes routing.com and hence the startup of TCPware to fail (at least it does on our system). I don't have a copy of the error message, but I believe the problem is that the Telnet service is not up and running by the time the 'modify' command is called, hence the modify command fails and so on. Trevor Cruse IS Systems Manager Cooper-Avon Tyres Limited Melksham England (0044) 1225 357858 tmcruse@coopertire.com ================================================================================ Archive-Date: Fri, 27 Oct 2000 08:39:50 -0400 Date: Fri, 27 Oct 2000 7:39:08 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <001027073908.202000c5@goatley.com> "Cruse, Trevor M." writes: > >Re: adding the command 'modify service telnet stream/options=nokeepalive' >to tcpware:routing.com. If you do this it causes routing.com and hence the >startup of TCPware to fail (at least it does on our system). I don't have a >copy of the error message, but I believe the problem is that the Telnet >service is not up and running by the time the 'modify' command is called, >hence the modify command fails and so on. > I thought all the services had been started by then. The actual contents of ROUTING.COM should be: $ run tcpware:netcu modify service telnet stream/options=nokeepalive exit $ exit Not just the MODIFY command by itself. I'm pretty sure ROUTING.COM is executed after services have been started, but if not, you could then put the commands in TCPWARE:SERVERS.COM, which is used to start user-provided servers. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Fri, 27 Oct 2000 09:03:41 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86030716D4@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: V72_MGMTAGENTS and TCPware Date: Fri, 27 Oct 2000 09:01:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I'm not sure which MGMTAGENTS you are asking about, but the next version of TCPware will have code in it that supports the Compaq Insight Manager XE agents (http://www.openvms.compaq.com/openvms/products/mgmt_agents/index.html). They will require an image from the Compaq's TCP/IP Services for OpenVMS V5.1 kit, which is the eSNMP library that the agents use for Agent X (RFC 2741) support. Note, that these management agents aren't cluster aware either. -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: Thursday, October 26, 2000 5:15 PM To: Info-TCPware@PROCESS.COM Subject: V72_MGMTAGENTS and TCPware After finding out, that the (long awaited) MGMTAGENTS are not compatbile with TCPware, we heard that "they will be supported soon". Is there any progress ? Is there already a TCPware SNMP agent which supports Q's V72_MGMTAGENTS as eSNMP subagents ? If not, when expected ? TCPware has still A LOT more features than Q's TCP/IPs and more still to come (SSH, SYSLOGD, future VMS extauth support, ...) hopefully. [e]SNMP seems to be so far the only disadvantage of TCPware (no UCX compatibility in this area ?) TIA PS: The V7x_MGMTAGENTS are not an example of good VMS programming. They are not cluster aware (eg. installed in SYS$SPECIFIC) -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Fri, 27 Oct 2000 10:55:25 -0400 Return-Path: From: "Richard Whalen" Reply-To: Info-TCPware@process.com Subject: Re: V72_MGMTAGENTS and TCPware Date: Fri, 27 Oct 2000 10:26:36 -0400 Message-ID: <8tc3b4$fgs$1@swen.process.com> To: Info-TCPware@process.com I'm not sure which MGMTAGENTS you are asking about, but the next version of TCPware will have code in it that supports the Compaq Insight Manager XE agents (http://www.openvms.compaq.com/openvms/products/mgmt_agents/index.html). They will require an image from the Compaq's TCP/IP Services for OpenVMS V5.1 kit, which is the eSNMP library that the agents use for Agent X (RFC 2741) support. Note, that these management agents aren't cluster aware either. -------------- Rich Whalen Process Software ================================================================================ Archive-Date: Sat, 28 Oct 2000 10:42:26 -0400 Return-Path: Subject: Re: V72_MGMTAGENTS and TCPware From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <39fae4d0$1@news.kapsch.co.at> Date: 28 Oct 2000 16:38:08 +0200 To: Info-TCPware@PROCESS.COM In article <8tc3b4$fgs$1@swen.process.com>, "Richard Whalen" writes: >I'm not sure which MGMTAGENTS you are asking about, but the next version of >TCPware will have code in it that supports the Compaq Insight Manager XE >agents >(http://www.openvms.compaq.com/openvms/products/mgmt_agents/index.html). These are the agents I was writing about. When can one expect the next version of TCPware ? Or why not a new SNMP image as an ECO for the current TCPware version ? >They will require an image from the Compaq's TCP/IP Services for OpenVMS >V5.1 kit, which is the eSNMP library that the agents use for Agent X (RFC >2741) support. > >Note, that these management agents aren't cluster aware either. Frustrasting... Thanks for reponding -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Mon, 30 Oct 2000 11:01:19 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86030716DC@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: V72_MGMTAGENTS and TCPware Date: Mon, 30 Oct 2000 09:59:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The next version of TCPware is currently expected to ship in late March of 2001. A new version the SNMP image isn't sufficient as we had to make some changes to another image as well to work around a bug in the C RTL. -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: Saturday, October 28, 2000 10:38 AM To: Info-TCPware@PROCESS.COM Subject: Re: V72_MGMTAGENTS and TCPware In article <8tc3b4$fgs$1@swen.process.com>, "Richard Whalen" writes: >I'm not sure which MGMTAGENTS you are asking about, but the next version of >TCPware will have code in it that supports the Compaq Insight Manager XE >agents >(http://www.openvms.compaq.com/openvms/products/mgmt_agents/index.html). These are the agents I was writing about. When can one expect the next version of TCPware ? Or why not a new SNMP image as an ECO for the current TCPware version ? >They will require an image from the Compaq's TCP/IP Services for OpenVMS >V5.1 kit, which is the eSNMP library that the agents use for Agent X (RFC >2741) support. > >Note, that these management agents aren't cluster aware either. Frustrasting... Thanks for reponding -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 31 Oct 2000 04:37:48 -0400 Return-Path: Subject: RE: V72_MGMTAGENTS and TCPware From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <39fe919e$1@news.kapsch.co.at> Date: 31 Oct 2000 10:32:14 +0100 To: Info-TCPware@PROCESS.COM In article <63D30D6E10CFD11190A90000F805FE86030716DC@lespaul.process.com>, Richard Whalen writes: >The next version of TCPware is currently expected to ship in late March of >2001. Yuck. Probably just days after my last maint contract ends :-( >A new version the SNMP image isn't sufficient as we had to make some changes >to another image as well to work around a bug in the C RTL. Did you see the latest ACRT ECOs (eg. for V7.2-1) ? Didn't it fix the bugs you mentioned ? Or do you want to keep the latest TCPware running on the last umpteen VMS versions and therefor have to workaround all available/found bugs in VMS/CRTL ? -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 31 Oct 2000 09:04:09 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86030716E5@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: V72_MGMTAGENTS and TCPware Date: Tue, 31 Oct 2000 09:03:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I haven't checked the patch list for a couple of months, so I don't know if there is a ACRT patch out that might have the bugs fixed. I'll have to look and see what has been patched recently. Since Compaq only supports the management agents on OpenVMS for Alpha V7.1 and later we don't expect there to be use of the agents on older versions of VMS. (Though our Agent X code is there and functional on all versions of VMS supported.) -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: Tuesday, October 31, 2000 4:32 AM To: Info-TCPware@PROCESS.COM Subject: RE: V72_MGMTAGENTS and TCPware In article <63D30D6E10CFD11190A90000F805FE86030716DC@lespaul.process.com>, Richard Whalen writes: >The next version of TCPware is currently expected to ship in late March of >2001. Yuck. Probably just days after my last maint contract ends :-( >A new version the SNMP image isn't sufficient as we had to make some changes >to another image as well to work around a bug in the C RTL. Did you see the latest ACRT ECOs (eg. for V7.2-1) ? Didn't it fix the bugs you mentioned ? Or do you want to keep the latest TCPware running on the last umpteen VMS versions and therefor have to workaround all available/found bugs in VMS/CRTL ? -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 31 Oct 2000 11:53:07 -0400 Date: Mon, 30 Oct 2000 23:51:08 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SMTP_V543P011 To: TCPware-Announce@PROCESS.COM Message-ID: <01JVYT62FKEA00BHED@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: SMTP_V543P011 Description: Fix BADBLOADDR on VAX; Fix INET channel leak on errors Release date: 31-OCT-2000 Ranking: 3 Max ranking: 3 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/smtp_v543p011.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. ----------------------------------------------------------- ----------------------------------------------------------------------- SMTP Patch kit (revision 1.1) for TCPware version 5.4-3 26-OCT-2000 Copyright (c) 2000, by Process Software This VMSinstallable saveset provides a new version of several SMTP images 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 changes have been made in this kit: - Provide a new version of the SMTP symbiont that can resolve names out of either the HOSTS file or DNS. (D/E 6266) ECO rank: 3 (corrects a specific problem) - Corrects a BADBLOADDR (bad block address) error on VAXen when mail is sent from VMS Mail and user-defined headers are present. (D/E 6453) ECO rank: 3 (corrects a specific problem) - Corrects a potential INET channel leak in certain error conditions. (D/E 6530) ECO rank: 3 (corrects a specific problem) After installing the patch kit you should do @TCPWARE:START_SMTP to cause the new images to be used. [End of ECO announcement]