Archive-Date: Fri, 3 Sep 1999 07:42:33 -0400 From: "Peter Jörg Ziegler" Reply-To: Info-TCPware@process.com Subject: Anybody has exp. with TCPW5.3-3 and Advanced Server? Need Help Date: Fri, 3 Sep 1999 12:37:03 +0200 Message-ID: <7qo8gj$bse$1@euler.space.net> To: Info-TCPware@PROCESS.COM The problem is that on AlphaVMS 7.2/TCPWare 5.3-3 the Advanced Server (Pathworks) is not willing to run over IP. PWRK$KNBDAEMON_.LOG says Fri Sep 3 10:36:12 1999 PH Address: AA-00-04-00-27-04 Fri Sep 3 10:36:12 1999 get_ip_addr: gethostbyname error: 0 Any hints? Best regards Joe ================================================================================ Archive-Date: Fri, 3 Sep 1999 07:42:40 -0400 Subject: Re: Anybody has exp. with TCPW5.3-3 and Advanced Server? Need Help From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <37cfa9d8@news.kapsch.co.at> Date: 3 Sep 1999 12:58:32 +0100 To: Info-TCPware@PROCESS.COM In article <7qo8gj$bse$1@euler.space.net>, "Peter Jörg Ziegler" writes: >The problem is that on AlphaVMS 7.2/TCPWare 5.3-3 the Advanced Server >(Pathworks) >is not willing to run over IP. > >PWRK$KNBDAEMON_.LOG says > Fri Sep 3 10:36:12 1999 PH Address: AA-00-04-00-27-04 > Fri Sep 3 10:36:12 1999 get_ip_addr: gethostbyname error: 0 *) BIND/DNS config ok ? Use NSLOOKUP to check. Reverse Lookup ok, too ? *) HOSTS. used instead ? All relevant nodes entered in hosts file ? *) PWIP started ? I already had problems with PATHWORKS over TCPware. With TCPware V5.0-3 the performance of PWIP was by a factor of 200 worse than UCX. Fixing the performance problem with patch/V5.0-4 caused TCPware PWIP (DECnet over IP, but not PATHWORKS) to crash my machines. But all other PATHWORKS problems were caused (and still exist in V6.0B ECO 1) by PATHWORKS and not by TCPware (KNB corrupts memory). I can't comment on ASOVMS, yet. Good luck -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Fri, 3 Sep 1999 09:21:49 -0400 Message-ID: <37CFCA16.5DDD679E@PROCESS.COM> Date: Fri, 03 Sep 1999 09:16:06 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: Anybody has exp. with TCPW5.3-3 and Advanced Server? Need Help Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > The problem is that on AlphaVMS 7.2/TCPWare 5.3-3 the Advanced Server > (Pathworks) is not willing to run over IP. > > PWRK$KNBDAEMON_.LOG says > Fri Sep 3 10:36:12 1999 PH Address: AA-00-04-00-27-04 > Fri Sep 3 10:36:12 1999 get_ip_addr: gethostbyname error: 0 The gethostbyname error indicates that it had a problem resolving a name. I'd make sure that the host name of the system can be resolved, both the fully qualified name and the non-fully qualified name. Try doing the following to see if the host's names can be resolved - $ NETCU SHOW HOST node.domain.com $ NETCU SHOW HOST node The NETCU SHOW HOST name uses the gethostbyname function. 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: Tue, 7 Sep 1999 06:03:57 -0400 From: WA@GURU1.SDA-ATS.CH (Chris J. WALTHER) Subject: SMTP: howto prevent from external misuse? Reply-To: Info-TCPware@process.com Message-ID: Date: Tue, 07 Sep 1999 09:58:06 GMT To: Info-TCPware@PROCESS.COM Hi! What can be done to prevent the SMTP server from being used from outside the company (for sending spam etc.)? We are running TCPWare 5.0-3. TIA --ChrisW ================================================================================ Archive-Date: Tue, 7 Sep 1999 06:25:42 -0400 Subject: Re: SMTP: howto prevent from external misuse? From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <37d4e62b@news.kapsch.co.at> Date: 7 Sep 1999 12:17:15 +0100 To: Info-TCPware@PROCESS.COM In article , WA@GURU1.SDA-ATS.CH (Chris J. WALTHER) writes: >What can be done to prevent the SMTP server from being used >from outside the company (for sending spam etc.)? We are >running TCPWare 5.0-3. You can't really do it. Better replace TCPware's SMTP server with MX V5.1 (or later). And consider upgrading to a more recent TCPware version. just my 0.02 -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Tue, 7 Sep 1999 06:59:21 -0400 Message-ID: <00dd01bef91f$25735390$150110ac@pcmv.pdv.intern> Reply-To: Info-TCPware@process.com From: "Martin Vorlaender" To: Subject: Re: SMTP: howto prevent from external misuse? Date: Tue, 7 Sep 1999 12:52:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Peter LANGSTOEGER wrote: >WA@GURU1.SDA-ATS.CH (Chris J. WALTHER) writes: >>What can be done to prevent the SMTP server from being used >>from outside the company (for sending spam etc.)? We are >>running TCPWare 5.0-3. > >You can't really do it. >Better replace TCPware's SMTP server with MX V5.1 (or later). >And consider upgrading to a more recent TCPware version. ...especially because v5.3-3 is the first version that is Y2k certified by PSC. cu, Martin -- | Martin Vorlaender VMS & WNT programmer OpenVMS is today | work: mv@pdv-systeme.de what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 7 Sep 1999 07:03:50 -0400 From: "Peter Jörg Ziegler" Reply-To: Info-TCPware@process.com Subject: Re: SMTP: howto prevent from external misuse? Date: Tue, 7 Sep 1999 12:53:27 +0200 Message-ID: <7r2quj$la5$1@euler.space.net> To: Info-TCPware@PROCESS.COM If you have only one system used for incomming and outgoing SMTP traffic you can do nothing, see comment from Peter LANGSTOEGER. Also newer version like actual 5.3-3 doesn t inhibit relaying. Best Regards Joe (Joerg Ziegler) Chris J. WALTHER schrieb in Nachricht ... >Hi! > >What can be done to prevent the SMTP server from being used >from outside the company (for sending spam etc.)? We are >running TCPWare 5.0-3. > >TIA > --ChrisW ================================================================================ Archive-Date: Tue, 7 Sep 1999 08:37:17 -0400 Sender: schreiber@process.com Date: Tue, 7 Sep 1999 08:31:24 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DDC93.D581126F.7@process.com> Subject: Re: SMTP: howto prevent from external misuse? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =22Peter J=F6rg Ziegler=22 writes: > >If you have only one system used for incomming and outgoing SMTP >traffic you can do nothing, see comment from Peter LANGSTOEGER. >Also newer version like actual 5.3-3 doesn t inhibit relaying. > There is SMTP relay filtering available in our latest version, 5.4, which is currently in beta. - Jeff -- Jeff Schreiber, Process Software Corp. schreiber=40mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 7 Sep 1999 15:23:00 -0400 From: WA@GURU1.SDA-ATS.CH (Chris J. WALTHER) Subject: Re: SMTP: howto prevent from external misuse? Reply-To: Info-TCPware@process.com Message-ID: Date: Tue, 07 Sep 1999 19:17:03 GMT To: Info-TCPware@PROCESS.COM On Tue, 7 Sep 1999 08:31:24 -0400, Jeff Schreiber wrote: > > There is SMTP relay filtering available in our latest version, 5.4, > which is currently in beta. First, thanks to everybody who answered my question for their input. ...and now to Process Software: When do you plan to make this release officially available? SMTP relay filtering most certainly is a very much needed feature nowadays. :-( -- ChrisW ================================================================================ Archive-Date: Tue, 7 Sep 1999 16:13:44 -0400 Sender: goatley@triton.process.com Return-Path: From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Re: SMTP: howto prevent from external misuse? Date: Tue, 7 Sep 1999 17:02:50 +0100 Message-ID: <7r3ctq$n28$1@mailgate.liffe.com> To: Info-TCPware@PROCESS.COM I thought that V5.3-2 was the first officially Y2K-compliant version... Martin Vorlaender wrote in message news:00dd01bef91f$25735390$150110ac@pcmv.pdv.intern... > > > ...especially because v5.3-3 is the first version that is > Y2k certified by PSC. > ================================================================================ Archive-Date: Tue, 7 Sep 1999 16:19:51 -0400 Message-ID: <37D571E9.5DFFE1BC@PROCESS.COM> Date: Tue, 07 Sep 1999 16:13:29 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: SMTP: howto prevent from external misuse? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > ...and now to Process Software: When do you plan to make this release > officially available? SMTP relay filtering most certainly is a very much needed > feature nowadays. :-( > If there are no unforeseen problems then TCPware 5.4 should be available by the end of October. regards Michael -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Wed, 8 Sep 1999 01:49:31 -0400 Message-ID: <002801bef9bd$0bee89f0$150110ac@pcmv.pdv.intern> Reply-To: Info-TCPware@process.com From: "Martin Vorlaender" To: CC: Subject: Re: SMTP: howto prevent from external misuse? Date: Wed, 8 Sep 1999 07:43:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Andy Williams wrote: >Martin Vorlaender wrote... >> ...especially because v5.3-3 is the first version that is >> Y2k certified by PSC. > >I thought that V5.3-2 was the first officially Y2K-compliant version... On http://www.process.com/multinet/news/year2000.htp it says 5.3 (with Scotty's words: "just 5.3; no bloody -1, -2 or -3"). Anyway, since the original poster had 5.0-something, it'd be a good idea to update to any 5.3-x. cu, Martin -- | Martin Vorlaender VMS & WNT programmer OpenVMS is today | work: mv@pdv-systeme.de what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Thu, 9 Sep 1999 09:12:25 -0400 Sender: bryant@process.com Date: Thu, 9 Sep 1999 09:06:25 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009DDE2B.0EBAA03C.85@process.com> Subject: Re: SMTP: howto prevent from external misuse? "Martin Vorlaender" writes: > >Andy Williams wrote: > >>Martin Vorlaender wrote... >>> ...especially because v5.3-3 is the first version that is >>> Y2k certified by PSC. >> >>I thought that V5.3-2 was the first officially Y2K-compliant version... > >On http://www.process.com/multinet/news/year2000.htp it says 5.3 (with >Scotty's words: "just 5.3; no bloody -1, -2 or -3"). > >Anyway, since the original poster had 5.0-something, it'd be a good idea >to update to any 5.3-x. While I don't remember which 5.3 version we listed first as Y2K compliant, I would indeed urge them to select 5.3-3. 5.3-3 was a maintainance release to 5.3-2 (and also included the pseudo-device feature, but let's not have the discussion of features in maintainence releases again...). As others have noted, TCPware 5.4 is currently in beta test, but if you are trying to be ready for Y2K, I imagine you want 5.3-3 now to be ready as soon as you can. >cu, > Martin >-- > | Martin Vorlaender VMS & WNT programmer > OpenVMS is today | work: mv@pdv-systeme.de > what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ > Windows NT 8.0 to be! | home: martin@radiogaga.harz.de > > ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Fri, 10 Sep 1999 16:45:18 -0400 Date: Fri, 10 Sep 1999 16:30:59 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: IMAP_V533P020 To: TCPware-Announce@PROCESS.COM Message-ID: <01JFT8KO6IKY00218G@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: IMAP_V533P020 Description: Numerous IMAP server fixes Release date: 10-SEP-1999 Versions: 5.3-3 ftp://ftp.process.com/support/53_3/imap_v533p020.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ------------------------------------------------------------------------- IMAP Patch kit (revision 2.0) for TCPware version 5.3-3 19-Aug-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of IMAP for TCPware for OpenVMS. It is applicable to TCPware version 5.3-3 and all supported versions of OpenVMS. The following changes have been made: 1) When using Microsoft Outlook or Outlook Express as an IMAP client, the IMAP server processes would be left in LEF state, and would have to be manually terminated, after Outlook terminated. The old version of IMAPD.EXE will be renamed to TCPWARE:IMAPD.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE:IMAPD.EXE ------------------------------------------------------------------------- IMAP Patch kit (revision 1.0) for TCPware version 5.3-3 14-Jun-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of IMAP for TCPware for OpenVMS. It is applicable to TCPware version 5.3-3 and all supported versions of OpenVMS. The following changes have been made: 1) The server has been upgraded to the IMAP4rev1 v11.241 server. 2) The IMAP server processes are no longer reused, as an attempt to reduce the occurance of "out of free storage" errors. !!!!IMPORTANT!!!! !!!!IMPORTANT!!!! The value of PGFLQUOTA for the SYSTEM account should be set to at least 50000 on VAX systems and 75000 on Alpha systems. This is due to a memory leak in the VMS MAILSHR shareable library that will occasionally cause an IMAP process to abort with an "out of free storage" error. Note that increasing the PGFLQUOTA parameter may require increasing the size of the system pagefiles. In addition, on VAX systems, it may be necessary to increase the value of the sysgen parameter VIRTUALPAGECNT. 3) On certain IMAP server aborts due to memory allocation failures, the VMS return error was not being logged. 4) If some RFC822 headers lines exceeded 255 bytes, one of the following could occur: - An IMAP server ACCVIO. - A "message not found" error returned to the IMAP client. - An error that contains no text returned to the IMAP client. 5) The IMAP server did not append the domain name to addresses containing only DECnet-style addresses. 6) The IMAP server would occasionally hang in a call to DECC$FPUT. 7) The IMAP server would generate an access violation when logging in as a username that did not have an entry in the system-wide VMSMAIL_PROFILE.DATA file (i.e, the user had not run MAIL yet). 8) Occasional access violations in the server caused deleted messages to end up in the WASTEBASKET folder and not get purged. 9) Miscellaneous other problems not related to customer defects have been corrected. The old version of IMAPD.EXE will be renamed to TCPWARE:IMAPD.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE:IMAPD.EXE [End of ECO announcement] ================================================================================ Archive-Date: Tue, 14 Sep 1999 13:25:43 -0400 Date: Tue, 14 Sep 1999 13:11:11 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: XNTP_V533P010 To: TCPware-Announce@PROCESS.COM Message-ID: <01JFYMRBZ2N60026FE@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: XNTP_V533P010 Description: XNTP fix for daylight savings time Release date: 14-SEP-1999 Versions: 5.3-3,5.3-2 ftp://ftp.process.com/support/53_3/xntp_v533p010.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- -------------------------------------------------------------------------------- NTP Patch kit (revision 1.0) for TCPware V5.3-3 5-Aug-1999 Copyright (c) 1999 by Process Software Corporation This VMSinstallable saveset provides a patched version of NTP for TCware for OpenVMS. NTP must be shut down before installing. This patch support TCPware V5.3-3 for VMS V5.5-2 thru V7.2. This patch kit requires the patch kit SOCKLIB_V533P010 be installed first. This patch kit provides the following files: NTPD.EXE XNTPDC.EXE NTPQ.EXE NTPTRACE.EXE NTPDATE.EXE The following changes have been made: - When a clock change occurs due to a daylight savings change, and slewalways is enabled, the TCPWARE_TIMEZONE logical is updated to the new timezone at the start of the slewing cycle. [D/E 1904] - When a clock change occurs due to a daylight savings change, a message will be output to the the log. NOTE Although the TCPWARE_TIMEZONE logical will be changed and the clock change message will be output at the time the daylight savings change occurs, the actual clock change may not start for several minutes. This is acceptable, and is due to the way the protocol behaves. The old version of the .EXE FILES will be renamed to TCPWARE_COMMON:[TCPWARE]*.EXE_OLD. Once installed, you may undo this patch by shutting down NTP, renaming the following files and restarting NTP: Rename To ---------------- ------------ NTPD.EXE_OLD NTPD.EXE XNTPDC.EXE_OLD XNTPDC.EXE NTPQ.EXE_OLD NTPQ.EXE NTPTRACE.EXE_OLD NTPTRACE.EXE NTPDATE.EXE_OLD NTPDATE.EXE Note that all files are in TCPWARE_COMMON:[TCPWARE]. [End of ECO announcement] ================================================================================ Archive-Date: Tue, 14 Sep 1999 14:44:22 -0400 Message-ID: <37DE960C.76BD8D03@wku.edu> Date: Tue, 14 Sep 1999 13:38:04 -0500 From: "Curtis Williams" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: TCPware ECO kit available: XNTP_V533P010 References: <01JFYMRBZ2N60026FE@DELTA.PROCESS.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit bryant@PROCESS.COM wrote: > TCPware ECO kit announcement > > The following ECO kit is now available for TCPware: > > ECO: XNTP_V533P010 > Description: XNTP fix for daylight savings time > Release date: 14-SEP-1999 > Versions: 5.3-3,5.3-2 > > ftp://ftp.process.com/support/53_3/xntp_v533p010.zip Where is the SOCKLIB kit that this kit requires? I can't find it in the 53_3 or 53_2 FTP location. -- | ____/ | /| / Curtis Williams, OpenVMS Systems Manager | | / | / | / Western Kentucky University | | /___ | / | / Network Computing, WAB 313 | | ______/ __/ __/ Bowling Green, KY 42101 USA | | USPA D-21076 Voice: 270-745-5251 Fax: 270-745-6014 | | INET: mailto:williamsca@wku.edu WWW: http://www2.wku.edu/~williamsca/ | | "Computer, you and I need to have a little talk." | | -- Miles O'Brien, Deep Space Nine | ================================================================================ Archive-Date: Thu, 16 Sep 1999 06:15:33 -0400 Subject: NETCU RELOAD NAMED From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <37e0ba15@news.kapsch.co.at> Date: 16 Sep 1999 11:36:21 +0100 To: Info-TCPware@PROCESS.COM is reloading the NAMED on all nodes in a cluster (I found it out the hard way) Is this expected behaviour ? NETCU HELP RELOAD NAMED and the manual doesn't help with this issue. -Peter PS: TCPware V5.4 seems to come RSN. Docu is already out... ftp://ftp.process.com/tcpware/tcpware054-doc.zip -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 16 Sep 1999 08:32:07 -0400 Sender: schreiber@process.com Date: Thu, 16 Sep 1999 08:25:51 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DE3A5.8C9CA1BD.31@process.com> Subject: RE: NETCU RELOAD NAMED eplan@kapsch.net (Peter LANGSTOEGER) writes: > >is reloading the NAMED on all nodes in a cluster (I found it out the hard way) > >Is this expected behaviour ? >NETCU HELP RELOAD NAMED and the manual doesn't help with this issue. > Fortunately it shouldn't hurt anything... This is corrected in 5.4. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 16 Sep 1999 09:05:01 -0400 Subject: RE: NETCU RELOAD NAMED From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <37e0e773@news.kapsch.co.at> Date: 16 Sep 1999 14:49:55 +0100 To: Info-TCPware@PROCESS.COM In article <009DE3A5.8C9CA1BD.31@process.com>, Jeff Schreiber writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >> >>is reloading the NAMED on all nodes in a cluster (I found it out the hard way) >> >>Is this expected behaviour ? >>NETCU HELP RELOAD NAMED and the manual doesn't help with this issue. > > Fortunately it shouldn't hurt anything... It DID hurt ! I did a SYSMAN SET E/N=(node1,node2) reload yesterday and then I ended up with a nameserver having a zone database file which was only 20% of the correct size because of the twice restart. A NAMED _should_ detect that its database is incomplete, but it didn't. And I was the initiator of the problems we got, because I did the RELOAD... > This is corrected in 5.4. How ? By adding a /CLUSTER qualifier (with /NOCLUSTER as default) to RELOAD NAMED ? That would be great... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 16 Sep 1999 09:21:44 -0400 Message-ID: From: "Cheryl A. Blake" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: RE: NETCU RELOAD NAMED Date: Thu, 16 Sep 1999 09:15:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi, not sure how I got myself involved in all the email about this... but it's not something I need to be involved in. Could you tell me how to take my name off this dist. ? thanks in advance, Cheryl -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: Thursday, September 16, 1999 9:50 AM To: Info-TCPware@PROCESS.COM Subject: RE: NETCU RELOAD NAMED In article <009DE3A5.8C9CA1BD.31@process.com>, Jeff Schreiber writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >> >>is reloading the NAMED on all nodes in a cluster (I found it out the hard way) >> >>Is this expected behaviour ? >>NETCU HELP RELOAD NAMED and the manual doesn't help with this issue. > > Fortunately it shouldn't hurt anything... It DID hurt ! I did a SYSMAN SET E/N=(node1,node2) reload yesterday and then I ended up with a nameserver having a zone database file which was only 20% of the correct size because of the twice restart. A NAMED _should_ detect that its database is incomplete, but it didn't. And I was the initiator of the problems we got, because I did the RELOAD... > This is corrected in 5.4. How ? By adding a /CLUSTER qualifier (with /NOCLUSTER as default) to RELOAD NAMED ? That would be great... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 16 Sep 1999 10:53:18 -0400 From: parlevjo@nbbs.nl Reply-To: Info-TCPware@process.com Subject: filename mapping problem novell disk Date: Thu, 16 Sep 1999 12:55:46 GMT Message-ID: <7rqpcc$8r1$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM I have a disk from a novell server mounted on the vax with tcpware-nfs. The problem is that filenames are converted. Eg: "Tmp.txt" is converted to the name "$T$MP.TXT". This is unneccesary because on novell you can not have a file called "tmp.txt" and "Tmp.txt" at the same time So i do not want to see the "$"'s. I want to see the same filenames as in FTP Does somebody know how i can disable this strange filename mapping My mount command is: $ nfsmount FS-LED-01 "/sys/update/vax" nfs5: /automount= (inactivity=00:10:00) testnfs /label="/vax" /system /uid=0/gid=0/noadf/noversion /convert=stream_crlf Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ================================================================================ Archive-Date: Thu, 16 Sep 1999 11:02:46 -0400 Sender: schreiber@process.com Date: Thu, 16 Sep 1999 10:56:29 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DE3BA.980E3FD8.27@process.com> Subject: RE: NETCU RELOAD NAMED "Cheryl A. Blake" writes: > >not sure how I got myself involved in all the email about this... but it's >not something I need to be involved in. Could you tell me how to take my >name off this dist. ? > Send mail to info-tcpware-request@process.com with "UNSUBSCRIBE" in the body of the message. - Jeff ================================================================================ Archive-Date: Thu, 16 Sep 1999 11:10:07 -0400 Sender: schreiber@process.com Date: Thu, 16 Sep 1999 11:03:51 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DE3BB.9F7DFED8.44@process.com> Subject: RE: NETCU RELOAD NAMED eplan@kapsch.net (Peter LANGSTOEGER) writes: > >It DID hurt ! > >I did a SYSMAN SET E/N=(node1,node2) reload yesterday >and then I ended up with a nameserver having a zone database file which >was only 20% of the correct size because of the twice restart. > Ok... I'm not totally following what might have happened. Was is that the one node started to load it's file from the reload, stopped, then didn't load it on the second pass? The answer to that is until you get 5.4, only do the reload to one of the nodes in the cluster! :) > >A NAMED _should_ detect that its database is incomplete, but it didn't. >And I was the initiator of the problems we got, because I did the RELOAD... > I'd need more information on the configuration to know exactly what might have happened. Was it the file that was incomplete, or what loaded into the nameserver? Was it a secondary or a primary? Are they both secondaries using the same backup zone file? Lots of questions. >> This is corrected in 5.4. > >How ? By adding a /CLUSTER qualifier (with /NOCLUSTER as default) >to RELOAD NAMED ? That would be great... No... the communication between the two changed quite a bit. Instead of the nameserver having a lock that NETCU attempts to take [thus triggering an AST in the server], NETCU uses a mailbox to send commands to the nameserver. This change allows for information to be passed easily between the two in the message... Like a debug level instead of having it re-read logicals that have to be set, or getting the version information from the server. -Jeff ================================================================================ Archive-Date: Thu, 16 Sep 1999 11:13:45 -0400 Message-ID: From: "Cheryl A. Blake" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: RE: NETCU RELOAD NAMED Date: Thu, 16 Sep 1999 11:07:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" thank you. -----Original Message----- From: Jeff Schreiber [mailto:schreiber@process.com] Sent: Thursday, September 16, 1999 10:56 AM To: Info-TCPware@process.com Cc: schreiber@process.com Subject: RE: NETCU RELOAD NAMED "Cheryl A. Blake" writes: > >not sure how I got myself involved in all the email about this... but it's >not something I need to be involved in. Could you tell me how to take my >name off this dist. ? > Send mail to info-tcpware-request@process.com with "UNSUBSCRIBE" in the body of the message. - Jeff ================================================================================ Archive-Date: Thu, 16 Sep 1999 11:31:43 -0400 Message-ID: <37E10BE1.1DE3E467@PROCESS.COM> Date: Thu, 16 Sep 1999 11:25:21 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: filename mapping problem novell disk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I have a disk from a novell server mounted on the vax with tcpware-nfs. > The problem is that filenames are converted. Eg: "Tmp.txt" is converted > to the name "$T$MP.TXT". > This is unneccesary because on novell you can not have a file called > "tmp.txt" and "Tmp.txt" at the same time > So i do not want to see the "$"'s. > I want to see the same filenames as in FTP > Does somebody know how i can disable this strange filename mapping > My mount command is: > $ nfsmount FS-LED-01 "/sys/update/vax" nfs5: /automount= > (inactivity=00:10:00) testnfs /label="/vax" /system > /uid=0/gid=0/noadf/noversion /convert=stream_crlf > The the /SEMANTICS=CASE_INSENSITIVE_FILENAMES. Here is the relevant section from help - /SEMANTICS { ADVISORY_CLOSE, } { CASE_INSENSITIVE_FILENAMES, } { NOFDL_FILES, } { } { NOLINKS, } { NOSTREAM_CONVERSION, } { NOUNIQUE_FILENO, } /SEMANTICS=( { } ) { NOVERSIONS, } { NOVMS_ACCESS_CHECKING, } { PRESERVE_DATES, } { } { UPPER_CASE_DEFAULT, } { VMS_FILENAMES, } { VMS_SERVER } { } Specifies capabilities and characteristics of the NFS Server that control the behavior of the MultiNet NFS Client, as described in the following table. Attribute Description ADVISORY_CLOSE Sends a VMS server a command to close the file when there are no more references to it on the client. CASE_INSENSITIVE_ Specifies that UNIX files accessed by FILENAMES an OpenVMS system not have their file names converted using the conversion characters (see HELP MULTINET File_ Name_Character_Map for a list of these characters). -- +-------------------------------------------------------------------------+ 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 -- +-------------------------------------------------------------------------+ 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: Thu, 16 Sep 1999 11:59:46 -0400 Message-ID: <039001bf005b$8aa11660$0e0d10ac@CN02638.nbbs.nl> From: "Johan Parlevliet" Reply-To: Info-TCPware@process.com To: CC: "Michael Corbett" Subject: Re: filename mapping problem novell disk Date: Thu, 16 Sep 1999 17:52:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks for your info. But our $ NFSMOUNT command does not have this qualifier. We are on version: $ netcu sh version TCPware(R) for OpenVMS V5.3-2 Copyright (c) 1997 Process Software Corporation -----Original Message----- From: Michael Corbett To: info-tcpware@process.com Date: donderdag, 16 september, 1999 17:33 Subject: RE: filename mapping problem novell disk >> I have a disk from a novell server mounted on the vax with tcpware-nfs. >> The problem is that filenames are converted. Eg: "Tmp.txt" is converted >> to the name "$T$MP.TXT". >> This is unneccesary because on novell you can not have a file called >> "tmp.txt" and "Tmp.txt" at the same time >> So i do not want to see the "$"'s. >> I want to see the same filenames as in FTP >> Does somebody know how i can disable this strange filename mapping >> My mount command is: >> $ nfsmount FS-LED-01 "/sys/update/vax" nfs5: /automount= >> (inactivity=00:10:00) testnfs /label="/vax" /system >> /uid=0/gid=0/noadf/noversion /convert=stream_crlf >> > >The the /SEMANTICS=CASE_INSENSITIVE_FILENAMES. Here is the relevant >section from help - > > > /SEMANTICS > > { ADVISORY_CLOSE, } > { CASE_INSENSITIVE_FILENAMES, } > { NOFDL_FILES, } > { } > { NOLINKS, } > { NOSTREAM_CONVERSION, } > { NOUNIQUE_FILENO, } > /SEMANTICS=( { } ) > { NOVERSIONS, } > { NOVMS_ACCESS_CHECKING, } > { PRESERVE_DATES, } > { } > { UPPER_CASE_DEFAULT, } > { VMS_FILENAMES, } > { VMS_SERVER } > { } > > Specifies capabilities and characteristics of the NFS Server that > control the behavior of the MultiNet NFS Client, as described in > the following table. > > Attribute Description > > ADVISORY_CLOSE Sends a VMS server a command to > close the file when there are no more > references to it on the client. > > CASE_INSENSITIVE_ Specifies that UNIX files accessed by > FILENAMES an OpenVMS system not have their file > names converted using the conversion > characters (see HELP MULTINET File_ > Name_Character_Map for a list of these > characters). > >-- >+-------------------------------------------------------------------------+ >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 > > >-- >+-------------------------------------------------------------------------+ >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: Thu, 16 Sep 1999 12:13:14 -0400 Message-ID: <37E1159B.2C2E3C9E@PROCESS.COM> Date: Thu, 16 Sep 1999 12:06:51 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: Re: filename mapping problem novell disk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Thanks for your info. > But our $ NFSMOUNT command does not have this qualifier. > We are on version: > $ netcu sh version > TCPware(R) for OpenVMS V5.3-2 Copyright (c) 1997 Process Software > Corporation > Sorry, I was thinking of the wrong product. There is no way to disable this with the TCPware NFS client. The only way to stop this from happening would be to make sure the server does not send over mixed case filenames. regards Michael -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Thu, 16 Sep 1999 12:22:18 -0400 Subject: RE: NETCU RELOAD NAMED From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <37e1136c@news.kapsch.co.at> Date: 16 Sep 1999 17:57:32 +0100 To: Info-TCPware@PROCESS.COM In article <009DE3BB.9F7DFED8.44@process.com>, Jeff Schreiber writes: > Ok... I'm not totally following what might have happened. Me, too. I had to do a quick (and dirty) hack from at home very early this morning to make things going again. So I simply deleted the zone database files and RELOADed again. I should have renamed them, so that I could now check them and answer your questions... > Was is that > the one node started to load it's file from the reload, stopped, then > didn't load it on the second pass? Both (Secondary) Server got reload signalled, checked the primary server for current versions, spawned a subprocess to do the zone transfer, got a second reload signalled and one of both servers ended up with a smaller zone database file, which it then didn't detect, that it is incomplete. So this server gave wrong information on requests. I can't give more information of causes, unfortunately... But it's still umpteen times better than a NT DNS (M$ or some others) where a reload does not exist and even a restart DNS service does not make the zone current either. So you always have to delete the zone database files by hand when restarting the DNS or need to wait for the domain refresh period (12h)... > The answer to that is until you get 5.4, only do the reload to one of > the nodes in the cluster! :) It's easy, when you know it. And if I avoid the trigger, this problem won't pop up again... >>A NAMED _should_ detect that its database is incomplete, but it didn't. >>And I was the initiator of the problems we got, because I did the RELOAD... > > I'd need more information on the configuration to know exactly what might > have happened. Was it the file that was incomplete, or what loaded into > the nameserver? Was it a secondary or a primary? Are they both > secondaries using the same backup zone file? Lots of questions. Primary server is another (UCX) node (my mgmt workstation) outside cluster. Both VMScluster servers - running TCPware - have (for performance reasons) a secondary nameserver (for all local domains) running. As the two servers are of different platform, they use different system disks. So their zonefiles resides on different places... btw: there is a common TCPware dir on a third disk for (config) files common for both platforms (eg. ROUTING.COM, HOSTS., BOOTPTAB., ...) >>> This is corrected in 5.4. >> >>How ? By adding a /CLUSTER qualifier (with /NOCLUSTER as default) >>to RELOAD NAMED ? That would be great... > > No... the communication between the two changed quite a bit. Instead > of the nameserver having a lock that NETCU attempts to take [thus > triggering an AST in the server], NETCU uses a mailbox to send commands > to the nameserver. This change allows for information to be passed > easily between the two in the message... Like a debug level instead of > having it re-read logicals that have to be set, or getting the version > information from the server. Documented ? In the Release Notes ? Or do I have to save this posting ? Thanks -Peter PS: Is it possible to fix the differences of the names of the BIND/DNS: $ @TCPWARE:RESTART DNS vs $ NETCU RELOAD NAMED eg. by allowing both names in both utilities. Yes, PLEASE -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 16 Sep 1999 14:07:21 -0400 Sender: schreiber@process.com Date: Thu, 16 Sep 1999 14:01:02 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DE3D4.60309524.171@process.com> Subject: RE: NETCU RELOAD NAMED eplan@kapsch.net (Peter LANGSTOEGER) writes: > >But it's still umpteen times better than a NT DNS (M$ or some others) >where a reload does not exist and even a restart DNS service does not >make the zone current either. So you always have to delete the zone >database files by hand when restarting the DNS or need to wait for the >domain refresh period (12h)... > One nice thing about the BIND 8 servers is DNS Notify. When a server is reloaded, it notifies it's secondaries that it has a new zone file. The secondaries can then transfer the updated zone without waiting for the refresh time. >> The answer to that is until you get 5.4, only do the reload to one of >> the nodes in the cluster! :) > >It's easy, when you know it. >And if I avoid the trigger, this problem won't pop up again... > *nod* It's something I actually forgot about way back when I implemented those. I didn't have the facilities at the time to test that situation [of all the servers on a cluster getting the reload attempt], and I forgot that it could happen. >> >> No... the communication between the two changed quite a bit. Instead >> of the nameserver having a lock that NETCU attempts to take [thus >> triggering an AST in the server], NETCU uses a mailbox to send commands >> to the nameserver. This change allows for information to be passed >> easily between the two in the message... Like a debug level instead of >> having it re-read logicals that have to be set, or getting the version >> information from the server. > >Documented ? In the Release Notes ? Or do I have to save this posting ? > I don't believe the change in the internal mechanism is documented, nor do I believe that it needs to be. New NETCU NameD commands are documented, and the fact that the TCPWARE_DNS_DEBUG, TCPWARE_NAMED_OPCOM_SEVERITY and TCPWARE_NAMED_LOGFILE_SEVERITY logicals have been obsoleted is documented in the 5.4 release notes. > >PS: Is it possible to fix the differences of the names of the BIND/DNS: >$ @TCPWARE:RESTART DNS vs $ NETCU RELOAD NAMED >eg. by allowing both names in both utilities. Yes, PLEASE > When I added the NETCU commands, I intentionally used "NAMED" rather than "DNS". The main point behind this is because of the historical confusion between the TCPWARE_NAMED and the TCPWARE_DNS process. I have considered changing @TCPWARE:RESTART DNS to @TCPWARE:RESTART NAMED [while still supporting an undocumented @TCPWARE:RESTART DNS], but since it's a tricky thing to change, and since it's really sort of just cosmetic, I've not had a chance to get to it yet. I'm not intending to add "DNS" to be synonymous with "NAMED" in the NETCU commands, just because that will be a step backward towards the NAMED vs. DNS process confusion. -Jeff ================================================================================ Archive-Date: Thu, 16 Sep 1999 17:29:47 -0400 Subject: RE: NETCU RELOAD NAMED From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <37e1563f@news.kapsch.co.at> Date: 16 Sep 1999 22:42:39 +0100 To: Info-TCPware@PROCESS.COM In article <009DE3D4.60309524.171@process.com>, Jeff Schreiber writes: > I don't believe the change in the internal mechanism is documented, nor > do I believe that it needs to be. Agreed. Though I always have problems, when the undocumented features/logicals exceeds the documented ones... > New NETCU NameD commands are documented, > and the fact that the TCPWARE_DNS_DEBUG, TCPWARE_NAMED_OPCOM_SEVERITY and > TCPWARE_NAMED_LOGFILE_SEVERITY logicals have been obsoleted is documented > in the 5.4 release notes. I hope, there is info, on how to debug NAMED and DNS in V5.4 then. >>PS: Is it possible to fix the differences of the names of the BIND/DNS: >>$ @TCPWARE:RESTART DNS vs $ NETCU RELOAD NAMED >>eg. by allowing both names in both utilities. Yes, PLEASE > > When I added the NETCU commands, I intentionally used "NAMED" rather than > "DNS". The main point behind this is because of the historical confusion > between the TCPWARE_NAMED and the TCPWARE_DNS process. I have considered > changing @TCPWARE:RESTART DNS to @TCPWARE:RESTART NAMED [while still > supporting an undocumented @TCPWARE:RESTART DNS], but since it's a tricky > thing to change, and since it's really sort of just cosmetic, I've not > had a chance to get to it yet. I agree, that this is not simple. But maybe I can/should help ? This is only DCL, so I've the sources ;-) btw. How to restart the DNS client (only) ? A @TCPWARE:RESTART DNS restarts the NAMED server and/or the DNS client ? How about adding a @TCPWARE:RESTART NAMED for the server only ? I think, it is not only cosmetic. It is a thing of consequency (to avoid as you wrote the historical confusion). > I'm not intending to add "DNS" to be synonymous with "NAMED" in the NETCU > commands, just because that will be a step backward towards the NAMED vs. > DNS process confusion. Agreed, but how about adding a "RExxxx DNS" for restarting the DNS client ? -Peter PS: I've still a lot of TCPWARE-W-DEFIGNORD messages in the DNS_CLIENT.LOG. Do you have an idea why ? I once opened a service call with V5.1, but no luck. -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 16 Sep 1999 17:47:58 -0400 Sender: schreiber@process.com Date: Thu, 16 Sep 1999 17:41:40 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DE3F3.32717A94.5@process.com> Subject: RE: NETCU RELOAD NAMED eplan@kapsch.net (Peter LANGSTOEGER) writes: > >> New NETCU NameD commands are documented, >> and the fact that the TCPWARE_DNS_DEBUG, TCPWARE_NAMED_OPCOM_SEVERITY and >> TCPWARE_NAMED_LOGFILE_SEVERITY logicals have been obsoleted is documented >> in the 5.4 release notes. > >I hope, there is info, on how to debug NAMED and DNS in V5.4 then. > Yes. the BIND 8 configuration file has an extensive logging section, which gives a _lot_ more control than you had with the TCPware features before [which were a lot more than BIND 4]. That stuff takes a little getting used to, but is quite powerful. >btw. How to restart the DNS client (only) ? >A @TCPWARE:RESTART DNS restarts the NAMED server and/or the DNS client ? >How about adding a @TCPWARE:RESTART NAMED for the server only ? >I think, it is not only cosmetic. It is a thing of consequency (to avoid >as you wrote the historical confusion). That's thing. @TCPWARE:RESTART DNS never touched the DNS process... it's always just restarted the NameD process [or at least that's the way it's been in the time that I've been involved]. > >> I'm not intending to add "DNS" to be synonymous with "NAMED" in the NETCU >> commands, just because that will be a step backward towards the NAMED vs. >> DNS process confusion. > >Agreed, but how about adding a "RExxxx DNS" for restarting the DNS client ? There is a way to restart the DNS process... but it is highly not recommended. There is a lot of things that go screwy when the DNS process is gone. NETCU STOP/DNS will stop the DNS process (likewise there is now a NETCU STOP/NAMED which is what @tcpware:shutnet DNS calls). To start the DNS process back up you have to @TCPWARE:STARTUP_RESOLVER DETACH If you have a system that you can play around with... try the following: NETCU STOP/DNS @TCPWARE:SHUTNET Trust me... the DNS process isn't ment to be messed with! :) > >PS: I've still a lot of TCPWARE-W-DEFIGNORD messages in the DNS_CLIENT.LOG. >Do you have an idea why ? I once opened a service call with V5.1, but no luck. > Yes... I know [about the call] :) The DNS process uses the LIB$ Tree stuff to store the hosts. services. and some other stuff. There is something in that stuff that tries to add the entries twice... I've not found the problem yet, and it might even be a small bug in the VMS code itself. However, it is just trying to add the records twice, and doesn't actually do any harm. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 17 Sep 1999 07:52:27 -0400 Subject: RE: NETCU RELOAD NAMED From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <37e227ce@news.kapsch.co.at> Date: 17 Sep 1999 13:36:46 +0100 To: Info-TCPware@PROCESS.COM In article <009DE3F3.32717A94.5@process.com>, Jeff Schreiber writes: > Yes. the BIND 8 configuration file has an extensive logging section, > which gives a _lot_ more control than you had with the TCPware features > before [which were a lot more than BIND 4]. That stuff takes a little > getting used to, but is quite powerful. Sounds great. > That's thing. @TCPWARE:RESTART DNS never touched the DNS process... it's > always just restarted the NameD process [or at least that's the way it's > been in the time that I've been involved]. Ok. So we all have the hope, that sometimes someone manages to fix this discrepancy. And in the meantime, lets ignore it. > There is a way to restart the DNS process... but it is highly not > recommended. There is a lot of things that go screwy when the DNS > process is gone. NETCU STOP/DNS will stop the DNS process (likewise > there is now a NETCU STOP/NAMED which is what @tcpware:shutnet DNS > calls). To start the DNS process back up you have to > > @TCPWARE:STARTUP_RESOLVER DETACH > > If you have a system that you can play around with... try the following: > > NETCU STOP/DNS > @TCPWARE:SHUTNET > > Trust me... the DNS process isn't ment to be messed with! :) Ok. But maybe sometimes... >>PS: I've still a lot of TCPWARE-W-DEFIGNORD messages in the DNS_CLIENT.LOG. >>Do you have an idea why ? I once opened a service call with V5.1, but no luck. > > Yes... I know [about the call] :) > > The DNS process uses the LIB$ Tree stuff to store the hosts. services. > and some other stuff. There is something in that stuff that tries to > add the entries twice... I've not found the problem yet, and it might > even be a small bug in the VMS code itself. However, it is just trying > to add the records twice, and doesn't actually do any harm. At least, now I got confirmation that this problem is not only my problem. That was the impression PSC gave me, at the time of the call. Because I never got troubles, I simply finished the call then... But it is not only twice. Currently I've logfiles showing that the DNS client tried at least 12 times to add a alias RSH or add a service NLM. I think, the DNS client restarts sometimes and keeps the same logfiles reruns the init and therefore add one another set of definitions (and error messages to the logfiles). I occasionally get OPCOM messages telling me, that the DNS client restarts. But I've the feeling (sometimes I check to be sure), that the OPCOM messages are not corresponding (means fewer) to the errormessages in the logfile. -- 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: Mon, 20 Sep 1999 10:17:49 -0400 Date: Mon, 20 Sep 1999 10:03:06 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SOCKLIB_V533P010 To: TCPware-Announce@PROCESS.COM Message-ID: <01JG6TX8BL8Y002CM4@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: SOCKLIB_V533P010 Description: Added code to support other ecos Release date: 20-SEP-1999 Versions: 5.3-3,5.3-2 ftp://ftp.process.com/support/53_3/socklib_v533p010.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- SOCKLIB Patch kit revision 1.0 for TCPware version 5.3-3 4-August-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of SOCKLIB.OLB for TCPware for OpenVMS. This patch is applicable to TCPware version 5.3-3 and all supported versions of OpenVMS. This patch is a requirement for applying certain other TCPware V5.3-3 patches. Please read the 'README.TXT' to check if this patch is a required. TCPWARE:SOCKLIB.OLB will be renamed to TCPWARE:SOCKLIB.OLB_OLD Once installed, you may undo this patch by renaming the old file back to its original extension. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 23 Sep 1999 08:43:13 -0400 Sender: bryant@process.com Date: Thu, 23 Sep 1999 08:36:28 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: PKASSAPI@PANAFON.GR CC: INFO-TCPWARE@PROCESS.COM, bryant@process.com Message-ID: <009DE927.31427FD1.17@process.com> Subject: RE: Advice on UCX to TCPWARE migration. >>From: pkassapi@panafon.gr >>X-Newsgroups: comp.os.vms >>Subject: Advice on UCX to TCPWARE migration. >>Date: Thu, 23 Sep 1999 13:55:25 +0200 >>Organization: Info-Vax<==>Comp.Os.Vms Gateway >>To: Info-VAX@Mvb.Saic.Com >> >>Hello! >> >>We are seriously considering (read: we are under heavy pressure!) to move >>from UCX to TCPware for a couple of systems around here due to application >>requirements, so I would like to hear whatever advice/suggestion/help the >>collective comp.os.vms mind can provide. >> >>The details: AlphaServers 4000 5/466 running OpenVMS V6.2-1H3. TCP/IP stack >>is currently provided by UCX V4.2 ECO 01 and is to be replaced by TCPware >>V5.3-3. Can I just install TCPware over UCX, or should I have to remove the >>latter first? Have you got any war stories to tell me? Any information >>provided to this end will be greatly appreciated. You do not need to remove UCX before installing TCPware. You might wish to remove UCX before hand to save on a bit of disk space, but it is not necessary. You can leave UCX around, and simply be sure to comment it out of your SYSTARTUP file so that it doesn't get started on a reboot. Once one of the two products has been started, a reboot is required to start the other. I would recommend that you be sure to have all your configuration information extracted before making the change. Make sure you know all your routing info, your interface addresses, DNS config, config for various servers etc. Keep in mind that TCPware defines commands as symbols via TCPWARE_COMMANDS.COM while UCX uses DCL commands. This might take a little getting used to in that once you have TCPware running if you say type TELN expecting TELNET and it uses the DCL command and complains about some UCX$ image, but if you type TELNET you will get the correct TCPware TELNET. It's not a problem, just an adjustment. Also, you may wish to follow the info-tcpware (vmsnet.networks.tcp-ip.tcpware) list vs. the info-vax (comp.os.vms) for help. It should go smoothly. Good luck, though I'm sure you won't need it. >>Thank you in advance for your help, >> >>Regards, >>Panayiotis >> >>---------- >>Panayiotis Kassapidis >>OpenVMS/UNIX System Manager >>Information Technology Dept. >>Computer Systems Center >>e-mail: pkassapi@panafon.gr ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 23 Sep 1999 09:00:35 -0400 From: Greg Thomas Reply-To: Info-TCPware@process.com Subject: Re: Advice on UCX to TCPWARE migration. Date: Thu, 23 Sep 1999 13:49:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM On Thu, 23 Sep 1999 08:36:28 -0400, Geoff Bryant wrote in article <009DE927.31427FD1.17@process.com>: >Keep in mind that TCPware defines commands as symbols via TCPWARE_COMMANDS.COM >while UCX uses DCL commands. This might take a little getting used to in that >once you have TCPware running if you say type TELN expecting TELNET and it uses >the DCL command and complains about some UCX$ image, but if you type TELNET you >will get the correct TCPware TELNET. It's not a problem, just an adjustment. Why doesn't TCPWARE_COMMANDS.COM define the symbol as $ TE*LNET == "$tcpware:telnet.exe" ! or wherever to get around the problem? Greg -- This post represents the views of the author and does not necessarily accurately represent the views of BT. ================================================================================ Archive-Date: Thu, 23 Sep 1999 09:11:18 -0400 Sender: bryant@process.com Date: Thu, 23 Sep 1999 09:04:41 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009DE92B.2239CCE3.170@process.com> Subject: Re: Advice on UCX to TCPWARE migration. Greg Thomas writes: > >On Thu, 23 Sep 1999 08:36:28 -0400, Geoff Bryant >wrote in article <009DE927.31427FD1.17@process.com>: > >>Keep in mind that TCPware defines commands as symbols via TCPWARE_COMMANDS.COM >>while UCX uses DCL commands. This might take a little getting used to in that >>once you have TCPware running if you say type TELN expecting TELNET and it uses >>the DCL command and complains about some UCX$ image, but if you type TELNET you >>will get the correct TCPware TELNET. It's not a problem, just an adjustment. > >Why doesn't TCPWARE_COMMANDS.COM define the symbol as > >$ TE*LNET == "$tcpware:telnet.exe" ! or wherever > >to get around the problem? I honestly don't know. That goes back before my time. I do know that if we made such a change, it is the sort of thing that will cause pain for some customers. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 23 Sep 1999 11:54:14 -0400 From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Advice on UCX to TCPWARE migration. Reply-To: Info-TCPware@process.com Message-ID: <1999Sep23.111917.1@eisner> Date: Thu, 23 Sep 1999 15:19:17 GMT To: Info-TCPware@PROCESS.COM In article , Greg Thomas writes: > Why doesn't TCPWARE_COMMANDS.COM define the symbol as > > $ TE*LNET == "$tcpware:telnet.exe" ! or wherever > > to get around the problem? That would make the unwarranted assumption that no customer is already using the abbreviation TE for something else. Certainly a customer can always define short symbol names, but it is quite rude for a vendor to do so. Of course I think it is rude for a vendor (including DEQ) to rely on symbols and foreign commands in the first place. Larry Kilgallen ================================================================================ Archive-Date: Thu, 23 Sep 1999 12:45:57 -0400 Message-ID: <19990923163920.52414.qmail@hotmail.com> From: "Mavis Deith" Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: NFS patch with VMS 7.1-2 Date: Thu, 23 Sep 1999 17:39:20 BST MIME-Version: 1.0 Content-Type: text/plain; format=flowed A client is looking to install NFSD_V532P010.A on a TCPware 5.3-2 system running under VMS 7.1-2 The readme for the patch says is is for VMS V5.5-2 thru V7.0 Can you please confirm it will also work OK on VMS 7.1-2. Thanks Mavis ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ================================================================================ Archive-Date: Fri, 24 Sep 1999 03:22:32 -0400 From: Robert Blum Subject: Re: Advice on UCX to TCPWARE migration. Date: Fri, 24 Sep 1999 02:09:07 -0500 Message-ID: <37EB2393.386DA96C@ix.netcom.com> Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Just to put my own two cents' worth in here... I worked on a system where we were running UCX, but switched to TCPware because of some issues with UCX NFS. We didn't really de-install the UCX product, just didn't call it in startup. We installed TCPware, and set up the foreign commands in the common system login. This worked fine, until one day after running a VMSINSTAL session. I got interrupted by a trouble call just after finishing the install (not TCPware or UCX), so without thinking I started to work on the problem. I typed "TELNET remotehost", logged in on the remote node, and resolved the problem. When I was done, I logged out, which took me back to the TCPware host I had run the install on. I typed "NETCU something", and did a double-take when it didn't understand the NETCU foreign command. It took a moment, but I finally realized that the VMSINSTAL had blown away all my symbol definitions - and I had run the UCX TELNET image over TCPware's BG device emulation! FTP worked as well, I tried it. Thank you again, Process Software. I've been happily using TCPware for years, and now I've just started working with MultiNet as well. Keep up the good work! Bob Blum P.S. - If you like living dangerously, carefully check out the DCL command SET COMMAND /DELETE. I've used it to eliminate a special command verb on a particular node in a cluster without creating separate DCL tables, and it can be used to remove the DCL commands UCX adds for TELNET, FTP, etc. Geoff Bryant wrote: > >>From: pkassapi@panafon.gr > >>X-Newsgroups: comp.os.vms > >>Subject: Advice on UCX to TCPWARE migration. > >>Date: Thu, 23 Sep 1999 13:55:25 +0200 > >>Organization: Info-Vax<==>Comp.Os.Vms Gateway > >>To: Info-VAX@Mvb.Saic.Com > >> > >>Hello! > >> > >>We are seriously considering (read: we are under heavy pressure!) to move > >>from UCX to TCPware for a couple of systems around here due to application > >>requirements, so I would like to hear whatever advice/suggestion/help the > >>collective comp.os.vms mind can provide. > >> > You do not need to remove UCX before installing TCPware. You might wish to > : > Keep in mind that TCPware defines commands as symbols via TCPWARE_COMMANDS.COM > while UCX uses DCL commands. This might take a little getting used to in that > once you have TCPware running if you say type TELN expecting TELNET and it uses > the DCL command and complains about some UCX$ image, but if you type TELNET you > will get the correct TCPware TELNET. It's not a problem, just an adjustment. > > Also, you may wish to follow the info-tcpware (vmsnet.networks.tcp-ip.tcpware) > list vs. the info-vax (comp.os.vms) for help. > > It should go smoothly. > > Good luck, though I'm sure you won't need it. > ------------------------------------------------------------- > Geoff Bryant bryant@process.com > TCPware/Multinet Engineering > Process Software Corporation http://www.process.com/ > 959 Concord St. > Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 27 Sep 1999 04:52:35 -0400 Message-ID: <19990927084550.71715.qmail@hotmail.com> From: "Mavis Deith" Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: RE: NFS patch with VMS 7.1-2 Date: Mon, 27 Sep 1999 09:45:50 BST MIME-Version: 1.0 Content-Type: text/plain; format=flowed No thoughts on this simple query??? >From: "Mavis Deith" >To: info-tcpware@process.com >Subject: NFS patch with VMS 7.1-2 >Date: Thu, 23 Sep 1999 17:39 +0100 > > >A client is looking to install NFSD_V532P010.A on a TCPware >5.3-2 system >running under VMS 7.1-2 > >The readme for the patch says is is for VMS V5.5-2 thru V7.0 > >Can you please confirm it will also work OK on VMS 7.1-2. > >Thanks > >Mavis > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ================================================================================ Archive-Date: Mon, 27 Sep 1999 09:26:30 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8690391F@lespaul.process.com> From: Mike Duffy Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NFS patch with VMS 7.1-2 Date: Mon, 27 Sep 1999 09:19:45 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Mavis, Sorry, I was not aware that you had not been answered. I don't know of any reason the kit should not work under V7.1-2. I believe it should work. However, I will check with the creator of the kit to make sure, and post the result here. I think I should be able to do so within the next three hours or so. Mike Duffy Process Software Corp. -----Original Message----- From: Mavis Deith [mailto:mavis_deith@hotmail.com] Sent: Monday, September 27, 1999 5:46 AM To: info-tcpware@process.com Subject: RE: NFS patch with VMS 7.1-2 No thoughts on this simple query??? >From: "Mavis Deith" >To: info-tcpware@process.com >Subject: NFS patch with VMS 7.1-2 >Date: Thu, 23 Sep 1999 17:39 +0100 > > >A client is looking to install NFSD_V532P010.A on a TCPware >5.3-2 system >running under VMS 7.1-2 > >The readme for the patch says is is for VMS V5.5-2 thru V7.0 > >Can you please confirm it will also work OK on VMS 7.1-2. > >Thanks > >Mavis > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ================================================================================ Archive-Date: Mon, 27 Sep 1999 11:15:48 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86903920@lespaul.process.com> From: Mike Duffy Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NFS patch with VMS 7.1-2 Date: Mon, 27 Sep 1999 11:09:02 -0400 MIME-Version: 1.0 Content-Type: text/plain Yes, this kit (and in general, all NFS client & server kits which work under V7.0) will work through V7.2 and probably beyond (we'll see). In general, most of our kit images linked against V7.0 will run under V7.1-2. Mike Duffy Process Software Corp. -----Original Message----- From: Mavis Deith [mailto:mavis_deith@hotmail.com] Sent: Monday, September 27, 1999 5:46 AM To: info-tcpware@process.com Subject: RE: NFS patch with VMS 7.1-2 No thoughts on this simple query??? >From: "Mavis Deith" >To: info-tcpware@process.com >Subject: NFS patch with VMS 7.1-2 >Date: Thu, 23 Sep 1999 17:39 +0100 > > >A client is looking to install NFSD_V532P010.A on a TCPware >5.3-2 system >running under VMS 7.1-2 > >The readme for the patch says is is for VMS V5.5-2 thru V7.0 > >Can you please confirm it will also work OK on VMS 7.1-2. > >Thanks > >Mavis > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ================================================================================ Archive-Date: Tue, 28 Sep 1999 02:17:28 -0400 Date: Tue, 28 Sep 1999 08:11:14 +0200 From: Alain Chappuis Reply-To: Info-TCPware@process.com Subject: Re: NFS patch with VMS 7.1-2 Sender: Alain.Chappuis@medecine.unige.ch To: Info-TCPware@process.com Message-ID: <37F07822.4C8EFB07@medecine.unige.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <63D30D6E10CFD11190A90000F805FE86903920@lespaul.process.com> Mike Duffy wrote: > > Yes, this kit (and in general, all NFS client & server kits which > work under V7.0) will work through V7.2 and probably beyond > (we'll see). In general, most of our kit images linked against V7.0 > will run under V7.1-2. But I will know if it is necessary to use this patch after multinet 4.2 rev A istalled and VMS 7.2 installed? I had big problems with multinet 4.1 and NFS one month ago... Thanks for your answer. Alain. -- +----------------------+-------------------------------------------+ | Alain Chappuis | Responsable du systeme cmu.unige.ch | | Analyste programmeur | Responsable des serveurs WEB medecine, JID| | Universite de Geneve | E-mail : Alain.Chappuis@medecine.unige.ch | | Centre Medical Univ. | Phone : +41 (22) [70]25.073 | | 1, Rue Michel-Servet | FAX : +41 (22) 347.33.34 | | CH-1211 Geneve 4 | WWW : http://www.medecine.unige.ch/ | +----------------------+-------------------------------------------+ ================================================================================ Archive-Date: Tue, 28 Sep 1999 03:35:49 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: DSNlink over tcpware Date: Tue, 28 Sep 1999 08:25:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi there, I've been struggling to get DSNlink running over TCPware using this mail as some information. Could anybody who has got this working give me an overview of what needs to be done. Cheers, Derek... -----Original Message----- From: Jim Mehlhop [mailto:mehlhop@process.com] Sent: 28 April 1999 15:15 To: Info-TCPware@process.com Subject: Re: DSNlink over tcpware At 01:40 PM 4/28/99 +0100, you wrote: >In article <1999Apr27.221126@alcor.process.com>, volz@process.com (Bernie Volz) writes: >>In article <37260ae2.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >>> 4) We defined services in TCPWARE:SERVERS.COM >>> >>> $ NETCU >>> add service 2370 tcp dsn$command:dsn_nsd.com >>> add service 2371 tcp dsn$command:dsn_copy.com >>> add service 2372 tcp dsn$command:dsn_mail.com >>> add service 2373 tcp dsn$command:dsn_its.com >>> add service 2374 tcp dsn$command:dsn_login.com >>> add service 2375 tcp dsn$command:dsn_netex.com >>> add service 2376 tcp dsn$command:dsn_sra.com >>> add service 2377 tcp dsn$command:dsn_k2.com >>> add service 2379 tcp dsn$command:dsn_file.com >> >>These are very likely incorrect. You want the bg_tcp, not tcp, service!!! >> >>You'll definitely want to use something more like: >>netcu> add service dsn_it bg_tcp /username=aes_dsnlink ... >> >>as mentioned in another posting. > >This is (since mentioned posting) on my To-Do List. >But our definitions were instructed by DEC, so someone have to tell them, >too. > >btw. What's the difference ? I never used BG_TCP, so far... The bg_tcp is the equivalent of flags=ucx_server in Multinet. This creates a service that is compatible with UCX which is what DSNLINK was written to work on. Jim > >------------------------------------------------------------------------ >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 > _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ *********************************************************************** 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 email 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 disemination, distribution or copying is strictly prohibited. If you have received this email in error please delete it immediately and advise us by return e-mail to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Tue, 28 Sep 1999 03:53:26 -0400 Message-ID: <37F07155.B6ACA3F6@email.sps.mot.com> Date: Tue, 28 Sep 1999 15:42:13 +0800 From: "Kumar Prem" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: DSNlink over tcpware References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi there.. Just wondering if anyone could tell me how do I go about getting the "PAK" license for Multinet version 4.2 package. It didnt come with the package when I bought it. Rgds, Prem. > > > -----Original Message----- > From: Jim Mehlhop [mailto:mehlhop@process.com] > Sent: 28 April 1999 15:15 > To: Info-TCPware@process.com > Subject: Re: DSNlink over tcpware > > At 01:40 PM 4/28/99 +0100, you wrote: > >In article <1999Apr27.221126@alcor.process.com>, volz@process.com (Bernie > Volz) writes: > >>In article <37260ae2.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter > LANGSTOEGER) writes: > >>> 4) We defined services in TCPWARE:SERVERS.COM > >>> > >>> $ NETCU > >>> add service 2370 tcp dsn$command:dsn_nsd.com > >>> add service 2371 tcp dsn$command:dsn_copy.com > >>> add service 2372 tcp dsn$command:dsn_mail.com > >>> add service 2373 tcp dsn$command:dsn_its.com > >>> add service 2374 tcp dsn$command:dsn_login.com > >>> add service 2375 tcp dsn$command:dsn_netex.com > >>> add service 2376 tcp dsn$command:dsn_sra.com > >>> add service 2377 tcp dsn$command:dsn_k2.com > >>> add service 2379 tcp dsn$command:dsn_file.com > >> > >>These are very likely incorrect. You want the bg_tcp, not tcp, service!!! > >> > >>You'll definitely want to use something more like: > >>netcu> add service dsn_it bg_tcp /username=aes_dsnlink ... > >> > >>as mentioned in another posting. > > > >This is (since mentioned posting) on my To-Do List. > >But our definitions were instructed by DEC, so someone have to tell them, > >too. > > > >btw. What's the difference ? I never used BG_TCP, so far... > > The bg_tcp is the equivalent of flags=ucx_server in Multinet. This creates > a service that is compatible with UCX which is what DSNLINK was written to > work on. > > Jim > > > > >------------------------------------------------------------------------ > >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 > > > > _________________________________________________________________________ > Jim Mehlhop, Support Engineer > Process Software > Mehlhop@process.com > Phone 719-638-8448 > Join Cauce to outlaw spam > http://www.cauce.org/ > > _________________________________________________________________________ > > *********************************************************************** > 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 email 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 > disemination, distribution or copying is strictly prohibited. If you > have received this email in error please delete it immediately and > advise us by return e-mail to administrator@itexjsy.com. > > *********************************************************************** ================================================================================ Archive-Date: Tue, 28 Sep 1999 08:57:37 -0400 Message-ID: From: "Kumar, Alok" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: DSNlink over tcpware Date: Tue, 28 Sep 1999 08:46:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Prem, Send the mail to support@process.com giving details of po etc. they'll forward your mail to sales team and you'll get the required PAK. I got my multinet PAK this way. Thanks Alok > -----Original Message----- > From: Kumar Prem [SMTP:r34124@email.sps.mot.com] > Sent: Tuesday, September 28, 1999 3:42 AM > To: Info-TCPware@process.com > Subject: Re: DSNlink over tcpware > > > Hi there.. > > Just wondering if anyone could tell me how do I go about getting the "PAK" > license for Multinet version 4.2 package. It didnt come with the package > when I > bought it. > > Rgds, > Prem. > > > > > > > -----Original Message----- > > From: Jim Mehlhop [mailto:mehlhop@process.com] > > Sent: 28 April 1999 15:15 > > To: Info-TCPware@process.com > > Subject: Re: DSNlink over tcpware > > > > At 01:40 PM 4/28/99 +0100, you wrote: > > >In article <1999Apr27.221126@alcor.process.com>, volz@process.com > (Bernie > > Volz) writes: > > >>In article <37260ae2.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter > > LANGSTOEGER) writes: > > >>> 4) We defined services in TCPWARE:SERVERS.COM > > >>> > > >>> $ NETCU > > >>> add service 2370 tcp dsn$command:dsn_nsd.com > > >>> add service 2371 tcp dsn$command:dsn_copy.com > > >>> add service 2372 tcp dsn$command:dsn_mail.com > > >>> add service 2373 tcp dsn$command:dsn_its.com > > >>> add service 2374 tcp dsn$command:dsn_login.com > > >>> add service 2375 tcp dsn$command:dsn_netex.com > > >>> add service 2376 tcp dsn$command:dsn_sra.com > > >>> add service 2377 tcp dsn$command:dsn_k2.com > > >>> add service 2379 tcp dsn$command:dsn_file.com > > >> > > >>These are very likely incorrect. You want the bg_tcp, not tcp, > service!!! > > >> > > >>You'll definitely want to use something more like: > > >>netcu> add service dsn_it bg_tcp /username=aes_dsnlink ... > > >> > > >>as mentioned in another posting. > > > > > >This is (since mentioned posting) on my To-Do List. > > >But our definitions were instructed by DEC, so someone have to tell > them, > > >too. > > > > > >btw. What's the difference ? I never used BG_TCP, so far... > > > > The bg_tcp is the equivalent of flags=ucx_server in Multinet. This > creates > > a service that is compatible with UCX which is what DSNLINK was written > to > > work on. > > > > Jim > > > > > > > > >------------------------------------------------------------------------ > > >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 > > > > > > > > _________________________________________________________________________ > > Jim Mehlhop, Support Engineer > > Process Software > > Mehlhop@process.com > > Phone 719-638-8448 > > Join Cauce to outlaw spam > > http://www.cauce.org/ > > > > > _________________________________________________________________________ > > > > *********************************************************************** > > 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 email 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 > > disemination, distribution or copying is strictly prohibited. If you > > have received this email in error please delete it immediately and > > advise us by return e-mail to administrator@itexjsy.com. > > > > *********************************************************************** ================================================================================ Archive-Date: Tue, 28 Sep 1999 09:39:59 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86903921@lespaul.process.com> From: Mike Duffy Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NFS patch with VMS 7.1-2 Date: Tue, 28 Sep 1999 09:33:10 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Alain, The patch kit being discussed was for TCPware, not MultiNet. (Please note this is the Info-TCPware group.) However, that statement is valid for the MultiNet ECO kits, as well as those for TCPware. To answer your question regarding the MultiNet patches; to date, each bug fixed for MultiNet NFS since the release of V4.2A is present in the base version (4.2A without any ECO's) under any version of VMS on both platforms, with only one exception. The bug fix regarding ACL processing is only meaningful under OpenVMS/VAX V7.x and OpenVMS/Alpha V6.x and V7.x. The symptom would not occur on other versions. You may wish to check the kit remarks to see if any of the symptoms apply to your site(s) before applying the kit; most sites would never notice these particular bugs, but some would. Mike Duffy MultiNet & TCPware engineering Process Software Corp. -----Original Message----- From: Alain Chappuis [mailto:Alain.Chappuis@medecine.unige.ch] Sent: Tuesday, September 28, 1999 2:11 AM To: Info-TCPware@process.com Subject: Re: NFS patch with VMS 7.1-2 Mike Duffy wrote: > > Yes, this kit (and in general, all NFS client & server kits which > work under V7.0) will work through V7.2 and probably beyond > (we'll see). In general, most of our kit images linked against V7.0 > will run under V7.1-2. But I will know if it is necessary to use this patch after multinet 4.2 rev A istalled and VMS 7.2 installed? I had big problems with multinet 4.1 and NFS one month ago... Thanks for your answer. Alain. -- +----------------------+-------------------------------------------+ | Alain Chappuis | Responsable du systeme cmu.unige.ch | | Analyste programmeur | Responsable des serveurs WEB medecine, JID| | Universite de Geneve | E-mail : Alain.Chappuis@medecine.unige.ch | | Centre Medical Univ. | Phone : +41 (22) [70]25.073 | | 1, Rue Michel-Servet | FAX : +41 (22) 347.33.34 | | CH-1211 Geneve 4 | WWW : http://www.medecine.unige.ch/ | +----------------------+-------------------------------------------+ ================================================================================ Archive-Date: Wed, 29 Sep 1999 11:00:33 -0400 Message-ID: <4.1.19990929084722.00b19b10@mehlhop.org> Date: Wed, 29 Sep 1999 08:51:19 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: RE: DSNlink over tcpware In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Also need to make the changes to some DSN files as per the article on DSN and Multinet. basically modify DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT To make sure they have your FULLY qualified address not just the node name. I found that I also needed to make changes to the DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT files in the data directories for each system - the IP address for some of our systems(unhf.unh.edu, for example), was set to "unhf." Not very useful when it appears that this is the address DEC uses to get back to you. All I had to do was tack on "unh.edu". Only change those node addresses with a hanging period. "request file"s didn't work until I fixed this. -- At 08:25 AM 9/28/99 +0100, you wrote: >Hi there, > >I've been struggling to get DSNlink running over TCPware using this mail as >some information. > >Could anybody who has got this working give me an overview of what needs to >be done. > >Cheers, > >Derek... > > >-----Original Message----- >From: Jim Mehlhop [mailto:mehlhop@process.com] >Sent: 28 April 1999 15:15 >To: Info-TCPware@process.com >Subject: Re: DSNlink over tcpware > > >At 01:40 PM 4/28/99 +0100, you wrote: >>In article <1999Apr27.221126@alcor.process.com>, volz@process.com (Bernie >Volz) writes: >>>In article <37260ae2.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter >LANGSTOEGER) writes: >>>> 4) We defined services in TCPWARE:SERVERS.COM >>>> >>>> $ NETCU >>>> add service 2370 tcp dsn$command:dsn_nsd.com >>>> add service 2371 tcp dsn$command:dsn_copy.com >>>> add service 2372 tcp dsn$command:dsn_mail.com >>>> add service 2373 tcp dsn$command:dsn_its.com >>>> add service 2374 tcp dsn$command:dsn_login.com >>>> add service 2375 tcp dsn$command:dsn_netex.com >>>> add service 2376 tcp dsn$command:dsn_sra.com >>>> add service 2377 tcp dsn$command:dsn_k2.com >>>> add service 2379 tcp dsn$command:dsn_file.com >>> >>>These are very likely incorrect. You want the bg_tcp, not tcp, service!!! >>> >>>You'll definitely want to use something more like: >>>netcu> add service dsn_it bg_tcp /username=aes_dsnlink ... >>> >>>as mentioned in another posting. >> >>This is (since mentioned posting) on my To-Do List. >>But our definitions were instructed by DEC, so someone have to tell them, >>too. >> >>btw. What's the difference ? I never used BG_TCP, so far... > >The bg_tcp is the equivalent of flags=ucx_server in Multinet. This creates >a service that is compatible with UCX which is what DSNLINK was written to >work on. > >Jim > > >> >>------------------------------------------------------------------------ >>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 >> > >_________________________________________________________________________ > Jim Mehlhop, Support Engineer > Process Software > Mehlhop@process.com > Phone 719-638-8448 > Join Cauce to outlaw spam > http://www.cauce.org/ > >_________________________________________________________________________ > > >*********************************************************************** >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 email 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 >disemination, distribution or copying is strictly prohibited. If you >have received this email in error please delete it immediately and >advise us by return e-mail to administrator@itexjsy.com. > >*********************************************************************** _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Wed, 29 Sep 1999 11:25:02 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: DSNlink over tcpware Date: Wed, 29 Sep 1999 16:14:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Jim, Where would I find this article (can't connect to DSN as I'm busy trying to upgrade it) 8-( I've tried making the changes as suggested, but all I get when I do a DSN NETEX or DSN ITS is the following: EXTEL::SYSTEM>dsn netex DSNlink V2.2C for OpenVMS Alpha Network Exerciser Utility Copyright (c) 1989, 1998 by Digital Equipment Corporation Digital Equipment Corporation Proprietary Service Tool All Rights Reserved Connecting to target cscuvo.digital.dsn. Please wait... --- DsnNetEx::FAILURE, Operation failed - DsnSession::GATEWAYERR, DsnGateway error - DsnGateway::NOPATH, No successful path found to remote server for "digital/cscuvo/Dsn_NetEx" whoami=05uk0005900-aesdn/extel/Dsn_NetEx One problem could be that this is a dual-homed system, and only one ethernet is connected to the internet (behind a firewall). I need to track down how it tries to find a route, but I'm kind of at a bit of a loss, and could do with some more clues. Cheers, Derek... -----Original Message----- From: Jim Mehlhop [mailto:mehlhop@mehlhop.org] Sent: 29 September 1999 15:51 To: Info-TCPware@process.com Subject: RE: DSNlink over tcpware Also need to make the changes to some DSN files as per the article on DSN and Multinet. basically modify DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT To make sure they have your FULLY qualified address not just the node name. I found that I also needed to make changes to the DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT files in the data directories for each system - the IP address for some of our systems(unhf.unh.edu, for example), was set to "unhf." Not very useful when it appears that this is the address DEC uses to get back to you. All I had to do was tack on "unh.edu". Only change those node addresses with a hanging period. "request file"s didn't work until I fixed this. -- At 08:25 AM 9/28/99 +0100, you wrote: >Hi there, > >I've been struggling to get DSNlink running over TCPware using this mail as >some information. > >Could anybody who has got this working give me an overview of what needs to >be done. > >Cheers, > >Derek... > > >-----Original Message----- >From: Jim Mehlhop [mailto:mehlhop@process.com] >Sent: 28 April 1999 15:15 >To: Info-TCPware@process.com >Subject: Re: DSNlink over tcpware > > >At 01:40 PM 4/28/99 +0100, you wrote: >>In article <1999Apr27.221126@alcor.process.com>, volz@process.com (Bernie >Volz) writes: >>>In article <37260ae2.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter >LANGSTOEGER) writes: >>>> 4) We defined services in TCPWARE:SERVERS.COM >>>> >>>> $ NETCU >>>> add service 2370 tcp dsn$command:dsn_nsd.com >>>> add service 2371 tcp dsn$command:dsn_copy.com >>>> add service 2372 tcp dsn$command:dsn_mail.com >>>> add service 2373 tcp dsn$command:dsn_its.com >>>> add service 2374 tcp dsn$command:dsn_login.com >>>> add service 2375 tcp dsn$command:dsn_netex.com >>>> add service 2376 tcp dsn$command:dsn_sra.com >>>> add service 2377 tcp dsn$command:dsn_k2.com >>>> add service 2379 tcp dsn$command:dsn_file.com >>> >>>These are very likely incorrect. You want the bg_tcp, not tcp, service!!! >>> >>>You'll definitely want to use something more like: >>>netcu> add service dsn_it bg_tcp /username=aes_dsnlink ... >>> >>>as mentioned in another posting. >> >>This is (since mentioned posting) on my To-Do List. >>But our definitions were instructed by DEC, so someone have to tell them, >>too. >> >>btw. What's the difference ? I never used BG_TCP, so far... > >The bg_tcp is the equivalent of flags=ucx_server in Multinet. This creates >a service that is compatible with UCX which is what DSNLINK was written to >work on. > >Jim > > >> >>------------------------------------------------------------------------ >>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 >> > >_________________________________________________________________________ > Jim Mehlhop, Support Engineer > Process Software > Mehlhop@process.com > Phone 719-638-8448 > Join Cauce to outlaw spam > http://www.cauce.org/ > >_________________________________________________________________________ > > >*********************************************************************** >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 email 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 >disemination, distribution or copying is strictly prohibited. If you >have received this email in error please delete it immediately and >advise us by return e-mail to administrator@itexjsy.com. > >*********************************************************************** _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ *********************************************************************** 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 email 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 disemination, distribution or copying is strictly prohibited. If you have received this email in error please delete it immediately and advise us by return e-mail to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Wed, 29 Sep 1999 12:01:13 -0400 Message-ID: <4.1.19990929095126.00b26dc0@mehlhop.org> Date: Wed, 29 Sep 1999 09:51:59 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: RE: DSNlink over tcpware In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I'll send it as an attachment to you email address. Jim At 04:14 PM 9/29/99 +0100, you wrote: >Thanks Jim, > >Where would I find this article (can't connect to DSN as I'm busy trying to >upgrade it) >8-( > >I've tried making the changes as suggested, but all I get when I do a DSN >NETEX or DSN ITS is the following: > >EXTEL::SYSTEM>dsn netex >DSNlink V2.2C for OpenVMS Alpha Network Exerciser Utility >Copyright (c) 1989, 1998 by Digital Equipment Corporation >Digital Equipment Corporation Proprietary Service Tool >All Rights Reserved > >Connecting to target cscuvo.digital.dsn. Please wait... >--- DsnNetEx::FAILURE, Operation failed > - DsnSession::GATEWAYERR, DsnGateway error > - DsnGateway::NOPATH, No successful path found to remote server > for "digital/cscuvo/Dsn_NetEx" > whoami=05uk0005900-aesdn/extel/Dsn_NetEx > >One problem could be that this is a dual-homed system, and only one ethernet >is connected to the internet (behind a firewall). > >I need to track down how it tries to find a route, but I'm kind of at a bit >of a loss, and could do with some more clues. > >Cheers, > >Derek... > >-----Original Message----- >From: Jim Mehlhop [mailto:mehlhop@mehlhop.org] >Sent: 29 September 1999 15:51 >To: Info-TCPware@process.com >Subject: RE: DSNlink over tcpware > > >Also need to make the changes to some DSN files as per the article on DSN >and Multinet. > >basically modify DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT >To make sure they have your FULLY qualified address not just the node name. > > > > >I found that I also needed to make changes to the DSN_CONFIG.DAT and >DSN_ROUTE_MAP.DAT files in the data directories for each system - the IP >address for some of our systems(unhf.unh.edu, for example), was set to >"unhf." Not very useful when it appears that this is the address DEC >uses to get back to you. All I had to do was tack on "unh.edu". Only >change those node addresses with a hanging period. >"request file"s didn't work until I fixed this. >-- >At 08:25 AM 9/28/99 +0100, you wrote: >>Hi there, >> >>I've been struggling to get DSNlink running over TCPware using this mail as >>some information. >> >>Could anybody who has got this working give me an overview of what needs to >>be done. >> >>Cheers, >> >>Derek... >> >> >>-----Original Message----- >>From: Jim Mehlhop [mailto:mehlhop@process.com] >>Sent: 28 April 1999 15:15 >>To: Info-TCPware@process.com >>Subject: Re: DSNlink over tcpware >> >> >>At 01:40 PM 4/28/99 +0100, you wrote: >>>In article <1999Apr27.221126@alcor.process.com>, volz@process.com (Bernie >>Volz) writes: >>>>In article <37260ae2.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter >>LANGSTOEGER) writes: >>>>> 4) We defined services in TCPWARE:SERVERS.COM >>>>> >>>>> $ NETCU >>>>> add service 2370 tcp dsn$command:dsn_nsd.com >>>>> add service 2371 tcp dsn$command:dsn_copy.com >>>>> add service 2372 tcp dsn$command:dsn_mail.com >>>>> add service 2373 tcp dsn$command:dsn_its.com >>>>> add service 2374 tcp dsn$command:dsn_login.com >>>>> add service 2375 tcp dsn$command:dsn_netex.com >>>>> add service 2376 tcp dsn$command:dsn_sra.com >>>>> add service 2377 tcp dsn$command:dsn_k2.com >>>>> add service 2379 tcp dsn$command:dsn_file.com >>>> >>>>These are very likely incorrect. You want the bg_tcp, not tcp, service!!! >>>> >>>>You'll definitely want to use something more like: >>>>netcu> add service dsn_it bg_tcp /username=aes_dsnlink ... >>>> >>>>as mentioned in another posting. >>> >>>This is (since mentioned posting) on my To-Do List. >>>But our definitions were instructed by DEC, so someone have to tell them, >>>too. >>> >>>btw. What's the difference ? I never used BG_TCP, so far... >> >>The bg_tcp is the equivalent of flags=ucx_server in Multinet. This creates >>a service that is compatible with UCX which is what DSNLINK was written to >>work on. >> >>Jim >> >> >>> >>>------------------------------------------------------------------------ >>>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 >>> >> >>_________________________________________________________________________ >> Jim Mehlhop, Support Engineer >> Process Software >> Mehlhop@process.com >> Phone 719-638-8448 >> Join Cauce to outlaw spam >> http://www.cauce.org/ >> >>_________________________________________________________________________ >> >> >>*********************************************************************** >>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 email 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 >>disemination, distribution or copying is strictly prohibited. If you >>have received this email in error please delete it immediately and >>advise us by return e-mail to administrator@itexjsy.com. >> >>*********************************************************************** > > >_________________________________________________________________________ > Jim Mehlhop, Support Engineer > Process Software > Mehlhop@process.com > Phone 719-638-8448 > Join Cauce to outlaw spam > http://www.cauce.org/ > >_________________________________________________________________________ > > >*********************************************************************** >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 email 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 >disemination, distribution or copying is strictly prohibited. If you >have received this email in error please delete it immediately and >advise us by return e-mail to administrator@itexjsy.com. > >*********************************************************************** _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Thu, 30 Sep 1999 09:19:34 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" CC: "'Steve.Begley@compaq.com'" , "'Henry.Klasinski@compaq.com'" Subject: RE: DSNlink over tcpware Date: Thu, 30 Sep 1999 14:09:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi there, I just thought I'd send an update as to what I needed to do to get it working (the services. file was the last problem I had to resolve). I have had DSN NETEX and DSN ITS working, as well as performing a service request review of my calls. I'm about to start testing creating new calls and downloading patches. The last thing I'd like to work out is how to get the services to create a log file in DSN$LOGS, as the /OUTPUT qualifier is not supported for bg_tcp services (anybody got any suggestions) ? 1. Add the following entries to TCPWARE:SERVERS.COM then run it: add service 2370 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_nsd_server.com add service 2371 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_copy_server.com add service 2372 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_mail_server.com add service 2373 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_its_server.com add service 2374 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_login_server.com add service 2375 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_netex_server.com add service 2376 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_sra_server.com add service 2377 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_k2_server.com add service 2379 bg_tcp /username=aes_dsnlink - /input=dsn$command:dsn_file_server.com 2. Add the following lines to TCPWARE:SERVICES. dsn_nsd 2370/tcp dsn_copy 2371/tcp dsn_mail 2372/tcp dsn_its 2373/tcp dsn_login 2374/tcp dsn_netex 2375/tcp dsn_sra 2376/tcp dsn_k2 2377/tcp dsn_file 2379/tcp 3. Check that all tcp entries in DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT are correct. Derek... -----Original Message----- From: Jim Mehlhop [mailto:mehlhop@mehlhop.org] Sent: 29 September 1999 15:51 To: Info-TCPware@process.com Subject: RE: DSNlink over tcpware Also need to make the changes to some DSN files as per the article on DSN and Multinet. basically modify DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT To make sure they have your FULLY qualified address not just the node name. I found that I also needed to make changes to the DSN_CONFIG.DAT and DSN_ROUTE_MAP.DAT files in the data directories for each system - the IP address for some of our systems(unhf.unh.edu, for example), was set to "unhf." Not very useful when it appears that this is the address DEC uses to get back to you. All I had to do was tack on "unh.edu". Only change those node addresses with a hanging period. "request file"s didn't work until I fixed this. -- At 08:25 AM 9/28/99 +0100, you wrote: >Hi there, > >I've been struggling to get DSNlink running over TCPware using this mail as >some information. > >Could anybody who has got this working give me an overview of what needs to >be done. > >Cheers, > >Derek... > > >-----Original Message----- >From: Jim Mehlhop [mailto:mehlhop@process.com] >Sent: 28 April 1999 15:15 >To: Info-TCPware@process.com >Subject: Re: DSNlink over tcpware > > >At 01:40 PM 4/28/99 +0100, you wrote: >>In article <1999Apr27.221126@alcor.process.com>, volz@process.com (Bernie >Volz) writes: >>>In article <37260ae2.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter >LANGSTOEGER) writes: >>>> 4) We defined services in TCPWARE:SERVERS.COM >>>> >>>> $ NETCU >>>> add service 2370 tcp dsn$command:dsn_nsd.com >>>> add service 2371 tcp dsn$command:dsn_copy.com >>>> add service 2372 tcp dsn$command:dsn_mail.com >>>> add service 2373 tcp dsn$command:dsn_its.com >>>> add service 2374 tcp dsn$command:dsn_login.com >>>> add service 2375 tcp dsn$command:dsn_netex.com >>>> add service 2376 tcp dsn$command:dsn_sra.com >>>> add service 2377 tcp dsn$command:dsn_k2.com >>>> add service 2379 tcp dsn$command:dsn_file.com >>> >>>These are very likely incorrect. You want the bg_tcp, not tcp, service!!! >>> >>>You'll definitely want to use something more like: >>>netcu> add service dsn_it bg_tcp /username=aes_dsnlink ... >>> >>>as mentioned in another posting. >> >>This is (since mentioned posting) on my To-Do List. >>But our definitions were instructed by DEC, so someone have to tell them, >>too. >> >>btw. What's the difference ? I never used BG_TCP, so far... > >The bg_tcp is the equivalent of flags=ucx_server in Multinet. This creates >a service that is compatible with UCX which is what DSNLINK was written to >work on. > >Jim > > >> >>------------------------------------------------------------------------ >>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 >> > >_________________________________________________________________________ > Jim Mehlhop, Support Engineer > Process Software > Mehlhop@process.com > Phone 719-638-8448 > Join Cauce to outlaw spam > http://www.cauce.org/ > >_________________________________________________________________________ > > >*********************************************************************** >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 email 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 >disemination, distribution or copying is strictly prohibited. If you >have received this email in error please delete it immediately and >advise us by return e-mail to administrator@itexjsy.com. > >*********************************************************************** _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ *********************************************************************** 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 email 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 disemination, distribution or copying is strictly prohibited. If you have received this email in error please delete it immediately and advise us by return e-mail to administrator@itexjsy.com. ***********************************************************************