Archive-Date: Fri, 5 Mar 1999 15:45:29 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86D9A1BC@lespaul.process.com> From: Lauren Maschio Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: Functionality Date: Fri, 5 Mar 1999 15:39:37 -0500 MIME-Version: 1.0 Content-Type: text/plain In the next releases of TCPware we were considering not including the following features. I wanted to know if you are currently using these features? * DNS syntax checking - the ability to check DNS syntax while the server is running. * Bootfile option to instruct a forwarding server to not cache the responses that it receives from its forward servers. Your feedback would be appreciated. ================================================================================ Archive-Date: Fri, 5 Mar 1999 15:51:58 -0400 Message-ID: <36E042E7.4A602484@mmaz.com> Date: Fri, 05 Mar 1999 13:47:35 -0700 From: Barry Treahy Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Functionality References: <63D30D6E10CFD11190A90000F805FE86D9A1BC@lespaul.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I do not use it often because I do not alter the host files frequently, but the DNS syntax checking was helpful during setup... Barry Lauren Maschio wrote: > In the next releases of TCPware we were considering not including the > following features. I wanted to know if you are currently using these > features? > * DNS syntax checking - the ability to check DNS syntax while the > server is running. > * Bootfile option to instruct a forwarding server to not cache the > responses that it receives from its forward servers. > > Your feedback would be appreciated. ================================================================================ Archive-Date: Fri, 5 Mar 1999 17:45:54 -0400 Date: Fri, 5 Mar 1999 16:39:34 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: MultiNet-Announce@PROCESS.COM, TCPware-Announce@PROCESS.COM, Info-TCPware@PROCESS.COM, Info-MultiNet@process.com Message-ID: <009D4AAF.36ED1D81.4@goat.process.com> Subject: Process Software will be participating in the VMS Hobbyist Program! Process Software is pleased to announce our participation in the OpenVMS Hobbyist Program, sponsored by DECUS, Compaq, and Montagar. Both MultiNet and TCPware will be made available to valid OpenVMS Hobbyist participants. We're setting up the registration pages as I type this. The URLs will be posted here as soon as they're ready, which should be no later than 12-MAR-1999. Until then, information on the OpenVMS Hobbyist Program can be found on: http://www.montagar.com/hobbyist/ For more information, check our Hobbyist pages after they're announced, or send e-mail to me at the address below. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 5 Mar 1999 17:46:12 -0400 Date: Fri, 5 Mar 1999 16:39:34 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: MultiNet-Announce@PROCESS.COM, TCPware-Announce@PROCESS.COM, Info-TCPware@PROCESS.COM, Info-MultiNet@process.com Message-ID: <009D4AAF.36ED1D81.4@goat.process.com> Subject: Process Software will be participating in the VMS Hobbyist Program! Process Software is pleased to announce our participation in the OpenVMS Hobbyist Program, sponsored by DECUS, Compaq, and Montagar. Both MultiNet and TCPware will be made available to valid OpenVMS Hobbyist participants. We're setting up the registration pages as I type this. The URLs will be posted here as soon as they're ready, which should be no later than 12-MAR-1999. Until then, information on the OpenVMS Hobbyist Program can be found on: http://www.montagar.com/hobbyist/ For more information, check our Hobbyist pages after they're announced, or send e-mail to me at the address below. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Mon, 15 Mar 1999 15:01:21 -0400 From: jones01@my-dejanews.com Reply-To: Info-TCPware@process.com Subject: Virtual Circuit Closed message in a FDDI and VMS Cluster @6.2 Date: Mon, 15 Mar 1999 19:44:53 GMT Message-ID: <7cjnvi$cl5$1@nnrp1.dejanews.com> To: Info-TCPware@PROCESS.COM I get the folowing message when upgrading my VAX VMS Cluster from 5.5-2h4 to 6.2, "PEA0, Virtual Circuit Closed". My config is a 2 node, 2 system disk, 1 shared raid array through FDDI/TurboChannel adpter cluster. I can boot the 1st node with the array. When the 2nd node comes in, half way through the mounts of the drive on the raid, the raid goes offline with the message above. I'm using one of the disks on the raid as a quorum disk. I know the 2H4 varient is required under 5.5 for FDDI. Does anyone know if there is a similar patch or firmware upgrade required for 6.2? -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ================================================================================ Archive-Date: Tue, 16 Mar 1999 16:16:22 -0400 Date: Tue, 16 Mar 1999 15:09:39 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: MultiNet-Announce@process.com, TCPware-Announce@process.com Message-ID: <009D5347.7989B384.19@goat.process.com> Subject: MultiNet and TCPware Hobbyist Licenses now available Process Software is pleased to announce its participation in the OpenVMS Hobbyist Program sponsored by DECUS and Compaq. The program will grant participants in the OpenVMS Hobbyist program a free Hobbyist license for MultiNet or TCPware. NOTE: You must have a valid OpenVMS Hobbyist VMS license PAK to participate in the Process Software Hobbyist Program. To register for your MultiNet or TCPware license, use your favorite browser to visit this web page: http://www.process.com/openvms/hobbyist.htm Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Thu, 18 Mar 1999 11:24:16 -0400 From: "Russell S. Leathe" Reply-To: Info-TCPware@process.com Subject: which product? Date: Thu, 18 Mar 1999 10:59:33 -0500 Message-ID: <7cr7pk$hqc$1@client2.news.psi.net> To: Info-TCPware@PROCESS.COM Is there any advantage to running TCPWare over Multinet? I would appreciate your comments. We are currently running Multinet 4.1b on several VAX and Alpha boxes running a mix of OpenVMS 6.1 and Alpha 7.2. russ -- Russell S. Leathe Systems Manager Gordon College russ@hope.gordonc.edu ================================================================================ Archive-Date: Thu, 18 Mar 1999 11:48:49 -0400 Message-ID: <36F12CD6.D421820E@PROCESS.COM> Date: Thu, 18 Mar 1999 11:41:58 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: which product? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Is there any advantage to running TCPWare over Multinet? I would appreciate > your comments. > > We are currently running Multinet 4.1b on several VAX and Alpha boxes > running a mix of OpenVMS 6.1 and Alpha 7.2. > Hi Russ, There are some advantages TCPware has over Multinet and some that Multinet has over TCPware. If you need classless domain routing (CIDR) then that would be and advantage TCPware has over Multinet. There are many differences in how the various applications behave, (i.e. FTP, SMTP, NFS) that some would consider advantages or disadvantages depending on personal preference. Personally, I find the Multinet configuration utilities easier to use then TCPware so I would consider that an advantage of Multinet. If Multinet currently supplies all the functionality that you need I don't think there is any reason to consider changing to TCPware. If there is something that you need that Multinet does not supply or you are unhappy with the way some feature or component works then let me know and I'll tell you if TCPware has the feature or implements it differently. 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, 18 Mar 1999 12:00:42 -0400 Message-ID: <36F12FA2.34C68EFA@PROCESS.COM> Date: Thu, 18 Mar 1999 11:53:54 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: which product? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Is there any advantage to running TCPWare over Multinet? I would appreciate > your comments. > > We are currently running Multinet 4.1b on several VAX and Alpha boxes > running a mix of OpenVMS 6.1 and Alpha 7.2. > Hi Russ, There are some advantages TCPware has over Multinet and some that Multinet has over TCPware. If you need classless domain routing (CIDR) then that would be and advantage TCPware has over Multinet. There are many differences in how the various applications behave, (i.e. FTP, SMTP, NFS) that some would consider advantages or disadvantages depending on personal preference. Personally, I find the Multinet configuration utilities easier to use then TCPware so I would consider that an advantage of Multinet. If Multinet currently supplies all the functionality that you need I don't think there is any reason to consider changing to TCPware. If there is something that you need that Multinet does not supply or you are unhappy with the way some feature or component works then let me know and I'll tell you if TCPware has the feature or implements it differently. 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, 24 Mar 1999 10:47:11 -0400 Message-ID: <36F8EDD7.72FE0FB0@SMTP.DeltaTel.RU> Date: Wed, 24 Mar 1999 16:51:19 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Q:TCPWare 5.3-3 & ONC RPC Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! I have a problem with compiling of *.C modules which is produced by RPCGEN from PRINT.X. PRINT.X is simple/example XDR definition from TCPWare's RPC samples. Where is problem ? Follows sequence of actions: $ rpcgen print.x $ dir Directory $1$DUA1130:[LAISHEV.TEMP] PRINT.H;1 PRINT.X;1 PRINT_CLNT.C;1 PRINT_SVC.C;1 PRINT_XDR.C;1 Total of 5 files. $ $ cc /nowarn PRINT_CLNT.C,PRINT_SVC.C,PRINT_XDR.C typedef uint_t ino_t; /* inode number (filesystem) */ ........................^ %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior declaration in this scope at line number 67 in file SYS $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 typedef uint_t ino_t; /* inode number (filesystem) */ ........................^ %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior declaration in this scope at line number 67 in file SYS $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 typedef uint_t ino_t; /* inode number (filesystem) */ ........................^ %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior declaration in this scope at line number 67 in file SYS $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 $ -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 24 Mar 1999 11:51:56 -0400 Sender: DLUTES@textron.com Message-ID: <36F8C22C.15DD90B7@cessna.textron.com> Date: Wed, 24 Mar 1999 10:45:00 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Q:TCPWare 5.3-3 & ONC RPC References: <36F8EDD7.72FE0FB0@SMTP.DeltaTel.RU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ruslan R. Laishev wrote: > > Hi All! > I have a problem with compiling of *.C modules which is produced by RPCGEN from > PRINT.X. > PRINT.X is simple/example XDR definition from TCPWare's RPC samples. Where is problem > ? [snip] > $ cc /nowarn PRINT_CLNT.C,PRINT_SVC.C,PRINT_XDR.C > > typedef uint_t ino_t; /* inode number (filesystem) */ > ........................^ > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > declaration in this scope at line number 67 in file SYS > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 [repeating error messages snipped here] The problem is that a definition of uint_t occurs in both SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H and a module that the C compiler is including from SYS$LIBRARY:RTLDEF.TLB. I'm not sure what version of VMS and CC you are running, but my copy of RTLDEF doesn't seem to have uint_t in it anywhere. At any rate, a work-around might be to edit TYPES.H and comment out the line "typedef unsigned int uint_t;" FWIW, help exists for all of the compiler messages: $ HELP CC MESSAGE in this particular case: $ HELP CC MESSAGE NOLINKAGE Of course, some of the explanations are a *little* cryptic... Dale ================================================================================ Archive-Date: Wed, 24 Mar 1999 14:48:18 -0400 Message-ID: <36F93EC5.1CE3869D@SMTP.DeltaTel.RU> Date: Wed, 24 Mar 1999 22:36:37 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Q:TCPWare 5.3-3 & ONC RPC Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi ! I understand what this message is mean, and I can edit TCPware's types.h (w/o problem), but I'm would like to have examples which works for "beginners". :) I use DEC C 6.0/alpha. From other hand, may be this problem reffer to DEC C. Dale Lutes wrote: > > Ruslan R. Laishev wrote: > > > > Hi All! > > I have a problem with compiling of *.C modules which is produced by RPCGEN from > > PRINT.X. > > PRINT.X is simple/example XDR definition from TCPWare's RPC samples. Where is problem > > ? > > [snip] > > > $ cc /nowarn PRINT_CLNT.C,PRINT_SVC.C,PRINT_XDR.C > > > > typedef uint_t ino_t; /* inode number (filesystem) */ > > ........................^ > > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > > declaration in this scope at line number 67 in file SYS > > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 > > [repeating error messages snipped here] > > The problem is that a definition of uint_t occurs in both > SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H and a module that > the C compiler is including from SYS$LIBRARY:RTLDEF.TLB. > I'm not sure what version of VMS and CC you are running, but > my copy of RTLDEF doesn't seem to have uint_t in it anywhere. > At any rate, a work-around might be to edit TYPES.H and > comment out the line "typedef unsigned int uint_t;" > > FWIW, help exists for all of the compiler messages: > $ HELP CC MESSAGE Thanks. I know this. > > in this particular case: > $ HELP CC MESSAGE NOLINKAGE > > Of course, some of the explanations are a *little* cryptic... > > Dale -- CU, Ruslan. +....................................................................+ Intl: +7 (901) 971-3222, Local: 116-3222 +http://www.radiusvms.com ........... SysMan Frying on the HailStorm + ================================================================================ Archive-Date: Wed, 24 Mar 1999 23:02:02 -0400 Subject: Re: Q:TCPWare 5.3-3 & ONC RPC Message-ID: <1999Mar24.225031@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 24 Mar 99 22:50:31 -0500 To: Info-TCPware@PROCESS.COM The examples were designed to run with VAX C and earlier versions of DEC C. Digital has changed the header files in DEC C extensively over time, adding more and more definitions that previously never existed. This often causes very nasty problems with new releases of DEC C. - Bernie Volz In article <36F8EDD7.72FE0FB0@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > Hi All! > I have a problem with compiling of *.C modules which is produced by RPCGEN from > PRINT.X. > PRINT.X is simple/example XDR definition from TCPWare's RPC samples. Where is problem > ? > > > Follows sequence of actions: > > $ rpcgen print.x > $ dir > > Directory $1$DUA1130:[LAISHEV.TEMP] > > PRINT.H;1 PRINT.X;1 PRINT_CLNT.C;1 PRINT_SVC.C;1 > PRINT_XDR.C;1 > > Total of 5 files. > $ > $ cc /nowarn PRINT_CLNT.C,PRINT_SVC.C,PRINT_XDR.C > > typedef uint_t ino_t; /* inode number (filesystem) */ > ........................^ > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > declaration in this scope at line number 67 in file SYS > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 > > typedef uint_t ino_t; /* inode number (filesystem) */ > ........................^ > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > declaration in this scope at line number 67 in file SYS > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 > > typedef uint_t ino_t; /* inode number (filesystem) */ > ........................^ > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > declaration in this scope at line number 67 in file SYS > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 > $ > -- > Be well, right now. > +OpenVMS [Sys|Net] HardWorker........................................+ > Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 > 191119,St.Petersburg,Transportny per. 3 116-3222 > Fax: +7 (812) 115-1035 > +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Thu, 25 Mar 1999 01:51:53 -0400 Message-ID: <36F9D5E1.8E052A5E@SMTP.DeltaTel.RU> Date: Thu, 25 Mar 1999 09:21:21 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Q:TCPWare 5.3-3 & ONC RPC Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Thanks. I'll wait 5.3-4 . :) Bernie Volz wrote: > > The examples were designed to run with VAX C and earlier versions of DEC C. > > Digital has changed the header files in DEC C extensively over time, > adding more and more definitions that previously never existed. This > often causes very nasty problems with new releases of DEC C. > > - Bernie Volz > > In article <36F8EDD7.72FE0FB0@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > > Hi All! > > I have a problem with compiling of *.C modules which is produced by RPCGEN from > > PRINT.X. > > PRINT.X is simple/example XDR definition from TCPWare's RPC samples. Where is problem > > ? > > > > > > Follows sequence of actions: > > > > $ rpcgen print.x > > $ dir > > > > Directory $1$DUA1130:[LAISHEV.TEMP] > > > > PRINT.H;1 PRINT.X;1 PRINT_CLNT.C;1 PRINT_SVC.C;1 > > PRINT_XDR.C;1 > > > > Total of 5 files. > > $ > > $ cc /nowarn PRINT_CLNT.C,PRINT_SVC.C,PRINT_XDR.C > > > > typedef uint_t ino_t; /* inode number (filesystem) */ > > ........................^ > > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > > declaration in this scope at line number 67 in file SYS > > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 > > > > typedef uint_t ino_t; /* inode number (filesystem) */ > > ........................^ > > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > > declaration in this scope at line number 67 in file SYS > > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 > > > > typedef uint_t ino_t; /* inode number (filesystem) */ > > ........................^ > > %CC-E-NOLINKAGE, In this declaration, "ino_t" has no linkage and has a prior > > declaration in this scope at line number 67 in file SYS > > $COMMON:[SYSLIB]DECC$RTLDEF.TLB;3. > > at line number 120 in file SYS$COMMON:[TCPWARE.INCLUDE.RPCXDR]TYPES.H;1 > > $ > > -- > > Be well, right now. > > +OpenVMS [Sys|Net] HardWorker........................................+ > > Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 > > 191119,St.Petersburg,Transportny per. 3 116-3222 > > Fax: +7 (812) 115-1035 > > +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Thu, 25 Mar 1999 04:22:31 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: Q:TCPWare 5.3-3 & ONC RPC Date: 25 Mar 1999 10:10:42 +0100 Message-ID: <36f9fd92.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <36F9D5E1.8E052A5E@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: >Thanks. I'll wait 5.3-4 . :) You wait for 5.3-4 ? Where did you hear of this TCPware version ? I only heard of a coming V5.4 (with a new DHCP server)... ------------------------------------------------------------------------ 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, 25 Mar 1999 10:29:26 -0400 Sender: bryant@process.com Date: Thu, 25 Mar 1999 10:22:47 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D5A31.E43A5404.108@process.com> Subject: Re: Q:TCPWare 5.3-3 & ONC RPC eplan@kapsch.net (Peter LANGSTOEGER) writes: > >In article <36F9D5E1.8E052A5E@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: >>Thanks. I'll wait 5.3-4 . :) No need to wait. While the example code should likely be updated, you should be able to handle using DEC C and the ONC RPC with TCPware 5.3-3. There are different versions of include files provided to handle this. I am not knowledgeable about the details of this and you should contact our support folks to get any questions you have answered. I see you .RU domain, so I don't know how you receive support, but you should - Read the documentation. The very beginning of chapter 12 of the TCPware 5.2 programmers guide (could be a different chapter in the 5.3 doc) describers the support for DEC with the DEC C socket routines, versus VAXC and the TCPware socket library. - If you still have questions, contact suppor. >You wait for 5.3-4 ? Where did you hear of this TCPware version ? > >I only heard of a coming V5.4 (with a new DHCP server)... While I do know what we plan to actually set the version number to for the next release, I won't be saying anything until the CDs are pressed and have gone out in shipping boxes. >------------------------------------------------------------------------ >Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 >Network and OpenVMS system manager Fax. +43 1 81111-888 >FBFV/Information Services E-mail eplan@kapsch.net ><<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN >A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" >"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 25 Mar 1999 10:35:24 -0400 From: Bob Plance Reply-To: Info-TCPware@process.com Subject: printer codes for a newbie vms?? Date: Thu, 25 Mar 1999 10:10:19 -0500 Message-ID: <36FA51DB.C85F6511@tcl.tec.sc.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM I am trying to print to a HP LASERJET 5M from vms 6.2. I have created a queue using the multinet configure/printer command and am using the ip address which has been assigned to that printer. The print command sends the file to the printer but the print out does not print correctly. The next line does not reset to the left side. I think I need some type of printer code in the module for the library which I created for that queue. Does anyone know how to put an escape "ESC" printer code into a vms file with a new type keyboard and what the printer code would be to reset the print head to the left side of the paper. I am new to this and any help would be appreciated. Thanks, Bob ================================================================================ Archive-Date: Thu, 25 Mar 1999 10:46:20 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B4F5@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: TCPware FTP Server Logging Date: Thu, 25 Mar 1999 15:39:56 -0000 MIME-Version: 1.0 Content-Type: text/plain Hi there, We're evaluating TCPware on a bunch of AlphaServers, and I've got a query regading FTP Server logging. We need to get infrmation on what files are uploaded and downloaded from our FTP server. Is there any way (or any plans to) allow for me to specify a log file that all FTP transfers performed by the server are written to ? Other info such as time use logs in, logs out would also be useful. MGFTP has these features, but we'd really like to use a commercial (with support contract) version. Regards, Derek Fage FTI Systems Manager Itex (Jersey) Ltd ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ================================================================================ Archive-Date: Thu, 25 Mar 1999 10:54:49 -0400 Message-ID: <54F85D7F6DE2D01184EF0000F8049535FC3E9E@MAIL04> From: "Senulis, Joseph A" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: printer codes for a newbie vms?? Date: Thu, 25 Mar 1999 09:53:56 -0600 MIME-Version: 1.0 Content-Type: text/plain Hi Bob, Using EDT, you can create an with: 27 That is, hit the "gold" key, on the numeric keypad, type 2 and 7 from the QWERTY keypad, again, and then 3 from the numeric keypad. Joseph Senulis Technical Support Specialist BEITA ET/8 Wisconsin Department of Natural Resources 101 South Webster Street, Box 7921 Madison, Wisconsin 53707-7921 608-266-0853 senulj@dnr.state.wi.us > ---------- > From: Bob Plance[SMTP:bplance@tcl.tec.sc.us] > Reply To: Info-TCPware@process.com > Sent: Thursday, March 25, 1999 9:10 AM > To: Info-TCPware@PROCESS.COM > Subject: printer codes for a newbie vms?? > > I am trying to print to a HP LASERJET 5M from vms 6.2. I have created a > queue using the multinet configure/printer command and am using the ip > address which has been assigned to that printer. The print command sends > the file to the printer but the print out does not print correctly. The > next line does not reset to the left side. I think I need some type of > printer code in the module for the library which I created for that > queue. Does anyone know how to put an escape "ESC" printer code into a > vms file with a new type keyboard and what the printer code would be to > reset the print head to the left side of the paper. I am new to this and > any help would be appreciated. > > > Thanks, > > Bob > ================================================================================ Archive-Date: Thu, 25 Mar 1999 11:03:08 -0400 Sender: DLUTES@textron.com Message-ID: <36FA0849.4AD21C99@cessna.textron.com> Date: Thu, 25 Mar 1999 09:56:25 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: printer codes for a newbie vms?? References: <36FA51DB.C85F6511@tcl.tec.sc.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, The reset sequence for an HP Laserjet is "E". Create a new file called RESET.TXT. If you are using a TPU-based editor (EVE perhaps), press the DO key and enter the QUOTE command at the prompt. It will tell you to press the key to be added. Enter CTRL-[. If you are a die-hard EDT editor user, press PF1, the numbers 2 and 7 (ESC is decimal 27), PF1 again, then keypad 3. Add the capital E to the file immediately after the ESC and exit. You can insert this file into your device control library: $ LIBRARY/TEXT/INSERT RESET.TXT SYS$COMMON:[SYSLIB]LJET_CTL Note that you will have to stop any queues that are already referencing LJET_CTL before you can do the insert. I don't know how you set this up for Multinet, but from the DCL prompt you would then: $ START/QUEUE queue_name/LIBRARY=LJET_CTL/SEPARATE=(RESET=(RESET)) Bob Plance wrote: > > I am trying to print to a HP LASERJET 5M from vms 6.2. I have created a > queue using the multinet configure/printer command and am using the ip > address which has been assigned to that printer. The print command sends > the file to the printer but the print out does not print correctly. The > next line does not reset to the left side. I think I need some type of > printer code in the module for the library which I created for that > queue. Does anyone know how to put an escape "ESC" printer code into a > vms file with a new type keyboard and what the printer code would be to > reset the print head to the left side of the paper. I am new to this and > any help would be appreciated. > > Thanks, > > Bob ================================================================================ Archive-Date: Thu, 25 Mar 1999 11:15:19 -0400 Date: Thu, 25 Mar 1999 09:10:47 -0700 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: printer codes for a newbie vms?? In-Reply-To: <36FA0849.4AD21C99@cessna.textron.com> References: <36FA51DB.C85F6511@tcl.tec.sc.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 09:56 AM 3/25/99 -0600, you wrote: >Bob, > >The reset sequence for an HP Laserjet is "E". Create a >new file called RESET.TXT. =20 > >If you are using a TPU-based editor (EVE perhaps), press the=20 >DO key and enter the QUOTE command at the prompt. It will=20 >tell you to press the key to be added. Enter CTRL-[. =20 > An easier way to insert an escape character in TPU is hit ^v then PF1 this will put =D2OP into the screen then hit delete 2 times so only the =D2 (escape) is= left Jim=20 = _________________________________________________________________________ Jim Mehlhop, Support Engineer =20 Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ ________________________________________________________________________= _ ================================================================================ Archive-Date: Thu, 25 Mar 1999 11:16:35 -0400 Sender: DLUTES@textron.com Message-ID: <36FA0B6E.5782FB5E@cessna.textron.com> Date: Thu, 25 Mar 1999 10:09:50 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: printer codes (more...) References: <36FA51DB.C85F6511@tcl.tec.sc.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Here's a little extra info that I forgot to include in my last message. First, there is nothing magical about the name LJET_CTL. It just happens to be what I named my printer control file, so I used it in my example. Feel free to use whatever you want. Second, I've got one of these printers in my shop and, in addition to my VMS users, there are a number of PC users who access the printer via a queue on some NT server. This causes a problem when one of the PC users switches to the 11 x 17 inch paper tray. So my full reset sequence reads: E&l2A which resets the printer then re-selects the 8-1/2 x 11 tray. Good Luck, Dale ================================================================================ Archive-Date: Thu, 25 Mar 1999 11:32:10 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86010327DB@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPware FTP Server Logging Date: Thu, 25 Mar 1999 11:25:29 -0500 MIME-Version: 1.0 Content-Type: text/plain All transactions are logged to a logfile called FTPSERVER_DTP.LOG in the default directory for the client. This file is purged with a /KEEP=3 by the start up file (TCPWARE:FTPSERVER_DTP.COM). Since requests from different concurrent sessions are handled by different processes it is difficult to log all transactions to all accounts to a central file. Are you looking for system wide logging, or per-user logging? The information about when the user logged in and logged out is in the VMS accounting file. ---------------------- Richard Whalen Process Software Corporation 508-879-6994x261 -----Original Message----- From: Derek Fage [mailto:Derekf@ITEXJSY.com] Sent: Thursday, March 25, 1999 10:40 AM To: Info-TCPware@process.com Subject: TCPware FTP Server Logging Hi there, We're evaluating TCPware on a bunch of AlphaServers, and I've got a query regading FTP Server logging. We need to get infrmation on what files are uploaded and downloaded from our FTP server. Is there any way (or any plans to) allow for me to specify a log file that all FTP transfers performed by the server are written to ? Other info such as time use logs in, logs out would also be useful. MGFTP has these features, but we'd really like to use a commercial (with support contract) version. Regards, Derek Fage FTI Systems Manager Itex (Jersey) Ltd ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ================================================================================ Archive-Date: Thu, 25 Mar 1999 11:50:28 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B4F7@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPware FTP Server Logging Date: Thu, 25 Mar 1999 16:45:17 -0000 MIME-Version: 1.0 Content-Type: text/plain Richard, I'm looking for system wide logging. We have client applications that use FTP to transfer files up and down, and this can occur many times during the day. Sometimes a client will say that the file they wanted to collect a couple of days ago was not able to be collected, and w must have a log that we can look at. Unfortunately, as Microsoft IIS server has this functionality, my managers are saying that we must have it in whatever FTP offering we use, and I deperately do NOT want to relay on MS products !. If this is not possible with the TCPware FTP server, I'll need to stick to the MadGoat FTP server, but my managers are not particularly into the idea of running production software that does not have a support contract. Is there any likelyhood of you adding this functionality, or is there any undocumented logicals normally used for debugging that we could use ? Derek... > -----Original Message----- > From: Richard Whalen [SMTP:whalenr@process.com] > Sent: 25 March 1999 16:25 > To: 'Info-TCPware@process.com' > Subject: RE: TCPware FTP Server Logging > > All transactions are logged to a logfile called FTPSERVER_DTP.LOG in > the > default directory for the client. This file is purged with a /KEEP=3 > by the > start up file (TCPWARE:FTPSERVER_DTP.COM). Since requests from > different > concurrent sessions are handled by different processes it is difficult > to > log all transactions to all accounts to a central file. Are you > looking for > system wide logging, or per-user logging? > > The information about when the user logged in and logged out is in the > VMS > accounting file. > > ---------------------- > Richard Whalen > Process Software Corporation > 508-879-6994x261 > > > -----Original Message----- > From: Derek Fage [mailto:Derekf@ITEXJSY.com] > Sent: Thursday, March 25, 1999 10:40 AM > To: Info-TCPware@process.com > Subject: TCPware FTP Server Logging > > > Hi there, > > We're evaluating TCPware on a bunch of AlphaServers, and I've got a > query regading FTP Server logging. > > We need to get infrmation on what files are uploaded and downloaded > from > our FTP server. > > Is there any way (or any plans to) allow for me to specify a log file > that all FTP transfers performed by the server are written to ? Other > info such as time use logs in, logs out would also be useful. MGFTP > has > these features, but we'd really like to use a commercial (with support > contract) version. > > Regards, > > Derek Fage > FTI Systems Manager > Itex (Jersey) Ltd > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > www.mimesweeper.com > ********************************************************************** ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ================================================================================ Archive-Date: Thu, 25 Mar 1999 14:35:21 -0400 Subject: RE: TCPware FTP Server Logging Message-ID: <1999Mar25.140649@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 25 Mar 99 14:06:49 -0500 To: Info-TCPware@PROCESS.COM Look up the TCPWARE_FTP_LOGFILE logical. This is a system-wide log and keeps a log of all incoming and outgoing files, as well as logins via FTP. It logs successful as well as unsuccessful requests (so you can see if people are trying to do things with FTP that they shouldn't be doing). It is documented on page 11-8 of the TCPware 5.3 Management Guide. This support has existed for a while, so it is not new to 5.3. In article <49B21CD935D0D011B4980000F875254F0154B4F7@RDPEXC01>, Derek Fage writes: > Richard, > > I'm looking for system wide logging. > > We have client applications that use FTP to transfer files up and down, > and this can occur many times during the day. Sometimes a client will > say that the file they wanted to collect a couple of days ago was not > able to be collected, and w must have a log that we can look at. > > Unfortunately, as Microsoft IIS server has this functionality, my > managers are saying that we must have it in whatever FTP offering we > use, and I deperately do NOT want to relay on MS products !. > > If this is not possible with the TCPware FTP server, I'll need to stick > to the MadGoat FTP server, but my managers are not particularly into the > idea of running production software that does not have a support > contract. > > Is there any likelyhood of you adding this functionality, or is there > any undocumented logicals normally used for debugging that we could use > ? ================================================================================ Archive-Date: Thu, 25 Mar 1999 18:02:47 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B4FC@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPware FTP Server Logging Date: Thu, 25 Mar 1999 22:57:49 -0000 MIME-Version: 1.0 Content-Type: text/plain I'd already looked at that, but it only logs file transfers for the anonymous account (well at least with v5.3-2 that I am using). In addition, I get no information about start/end times of the transfers, or whether it was binary or ascii. These are things that are quite important to give be able to give real quality of service to FTP clients, especially if you need to investigate problems or accesses over a period of time. (And even more so if you want to bill them based on that information !!!) Regards, Derek... > -----Original Message----- > From: volz@process.com [SMTP:volz@process.com] > Sent: 25 March 1999 19:07 > To: Info-TCPware@PROCESS.COM > Subject: RE: TCPware FTP Server Logging > > Look up the TCPWARE_FTP_LOGFILE logical. This is a system-wide log and > keeps a log of all incoming and outgoing files, as well as logins via > FTP. It logs successful as well as unsuccessful requests (so you can > see if people are trying to do things with FTP that they shouldn't be > doing). > > It is documented on page 11-8 of the TCPware 5.3 Management Guide. > This support has existed for a while, so it is not new to 5.3. > > In article <49B21CD935D0D011B4980000F875254F0154B4F7@RDPEXC01>, Derek > Fage writes: > > Richard, > > > > I'm looking for system wide logging. > > > > We have client applications that use FTP to transfer files up and > down, > > and this can occur many times during the day. Sometimes a client > will > > say that the file they wanted to collect a couple of days ago was > not > > able to be collected, and w must have a log that we can look at. > > > > Unfortunately, as Microsoft IIS server has this functionality, my > > managers are saying that we must have it in whatever FTP offering we > > use, and I deperately do NOT want to relay on MS products !. > > > > If this is not possible with the TCPware FTP server, I'll need to > stick > > to the MadGoat FTP server, but my managers are not particularly into > the > > idea of running production software that does not have a support > > contract. > > > > Is there any likelyhood of you adding this functionality, or is > there > > any undocumented logicals normally used for debugging that we could > use > > ? ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ================================================================================ Archive-Date: Thu, 25 Mar 1999 22:18:28 -0400 Subject: RE: TCPware FTP Server Logging Message-ID: <1999Mar25.185221@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 25 Mar 99 18:52:21 -0500 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F0154B4FC@RDPEXC01>, Derek Fage writes: > I'd already looked at that, but it only logs file transfers for the > anonymous account (well at least with v5.3-2 that I am using). Yes, that is correct. It does log all logins, but not file transfers (file transfers only for anonymous users). Sorry. > > In addition, I get no information about start/end times of the > transfers, or whether it was binary or ascii. Correct. The time is the end time. You might be able to "guess" at the start time from the previous transfer for that user or when they logged in. Not sure why file format is that important (except perhaps to confirm that they transferred a file in the correct format). > These are things that are quite important to give be able to give real > quality of service to FTP clients, especially if you need to investigate > problems or accesses over a period of time. (And even more so if you > want to bill them based on that information !!!) > I'd suggest contacting our technical support folks and asking for an enhancement request. I don't see why we couldn't add these features, but yes they are not there today. - Bernie Volz Process Software ================================================================================ Archive-Date: Fri, 26 Mar 1999 15:04:27 -0400 Date: Fri, 26 Mar 1999 14:57:44 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: POP3_V533P020 To: TCPware-Announce@PROCESS.COM Message-ID: <01J9AGD1BVTU001FLC@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: POP3_V533P020 Description: POP3 fixes for message sizes and TOP command Release date: 26-MAR-1999 Versions: 5.3-3,5.3-2,5.2-3,5.1-5,5.1-4,5.0-4 ftp://ftp.process.com/support/53_3/pop3_v533p020.zip To search the TCPware ECO database, please visit the following URL: http://www.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ----------------------------------------------------------------------- POP3 Patch kit (revision 2.0) for TCPware version 5.3-3 04-Mar-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of POP3 for TCPware for OpenVMS. POP3 must be shut down before installing. You must restart the component after installation. This patch is applicable to TCPware 5.0-4 or higher on all the supported version of OpenVMS VAX and OpenVMS Alpha. The following problems have been corrected in this patch: 1. The message size calculated for each message could have been very incorrect for smaller messages. 2. The number of octets calculated for the segment of the message displayed as a result of a TOP command would be incorrect. 3. The TOP command worked correctly only for messages created by and sent to VMSmail accounts. For messages delivered to the VMS server via rfc822-compatible agents, the TOP command returned incorrect amounts of data. The old version of componentname will be renamed to TCPWARE_COMMON:[TCPWARE]POP3D.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE_COMMON:[TCPWARE]POP3D.EXE and restarting POP3 component. ----------------------------------------------------------------------- POP3 Patch kit (revision 1.0) for TCPware version 5.3-3 21-Jul-1998 Copyright (c) 1998, by Process Software Corporation This VMSinstallable saveset provides a new version of POP3 for TCPware for OpenVMS. POP3 must be shut down before installing, you must restart the component after installation. This patch is applicable to TCPware 5.0-4 or higher on all the supported version of VAX/VMS and OpenVMS. The following change has been made: 1. POP3 server now deny access to expired account. This feature can be disabled by the logical: $ DEFINE/SYSTEM/EXEC TCPWARE_POP3_ALLOW_EXPIRED "TRUE" [End of ECO announcement] ================================================================================ Archive-Date: Mon, 29 Mar 1999 03:35:56 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B512@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: TCPware REXEC Server Issues Date: Mon, 29 Mar 1999 09:30:23 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, We have a PC based application that issues REXEC commands to our OpenVMS cluster to get certin information that it needs. This was developed when we used UCX on our OpenVMS systems, but having installed TCPware it has started failing. Investigation shows that this is due to the TCPware REXEC server adding an additional CR to each record that is sent back. A simple test where you use REXEC to execute a DCL command procedure that writes "test line 1" to sys$output can demonstrate the problem. With both UCX 4.x and 5.x the line is returned to the client followf by CR LF. With TCPware, the line is returned with CR CR LF. Is there any logicals I can set to get rid of the extra CR ? (I need to do this on the server as we have about 400 clients currently using the client software located around UK/Europe/Far East) Regards, Derek... ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ================================================================================ Archive-Date: Mon, 29 Mar 1999 04:51:19 -0400 Date: Mon, 29 Mar 1999 10:20:44 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: Interaction between NTP and OpenVMS V7.1 To: info-tcpware@process.com Message-ID: <99Mar29.104625bst.17978@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN TCPWare V5.2-3 OpenVMS V7.1 DECnet OSI V7.1 ECO 2 We are running with the NTP server enabled under TCPware. DTSS from with DECnet/OSI is turned off. What if any effect does the TCPware service have upon the SYS$TIMEZONE_* logicals under OpenVMS? We have recently gone from GMT to BST and these logicals remain unchanged. "SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]GB-EIRE." "SYS$TIMEZONE_DAYLIGHT_SAVING" = "0" "SYS$TIMEZONE_DIFFERENTIAL" = "0" "SYS$TIMEZONE_NAME" = "GMT" "SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.5.0/1,M10.4.0/1" "TCPWARE_TIMEZONE" = "+000000" Many thanks /Steve ================================================================================ Archive-Date: Mon, 29 Mar 1999 08:24:26 -0400 Date: Mon, 29 Mar 1999 07:17:34 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <009D5D3C.AE2DD2BF.21@ALPHA.WKU.EDU> Subject: RE: TCPware REXEC Server Issues Derek Fage writes: > >This was developed when we used UCX on our OpenVMS systems, but having >installed TCPware it has started failing. Investigation shows that this >is due to the TCPware REXEC server adding an additional CR to each >record that is sent back. > Coincidentally, I was working on this very problem just this past week. >A simple test where you use REXEC to execute a DCL command procedure >that writes "test line 1" to sys$output can demonstrate the problem. >With both UCX 4.x and 5.x the line is returned to the client followf by >CR LF. With TCPware, the line is returned with CR CR LF. > >Is there any logicals I can set to get rid of the extra CR ? (I need to >do this on the server as we have about 400 clients currently using the >client software located around UK/Europe/Far East) > A fix for this should be available in a couple of days. Hunter ------ Hunter Goatley, Process Software, http://www.process.com http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 30 Mar 1999 11:20:35 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Refresh TCPware host cache Date: Tue, 30 Mar 1999 16:33:57 +0100 Message-ID: <7dqqsd$ehe$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM I've only just discovered this news group, so apologies if this has been asked before... Is there a way to force TCPware to re-read the HOSTS file immediately after it's been edited ? We have an isolated test network that we're currently adding systems to. Some of these systems are running in simulated live mode so we can't stop & restart TCPware. However, if we edit the HOSTS file we've noticed it can take up to about 10-15 minutes before the changes are picked up... Thanks for any help ! -Andy ================================================================================ Archive-Date: Tue, 30 Mar 1999 11:37:31 -0400 Sender: schreiber@process.com Date: Tue, 30 Mar 1999 11:30:40 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D5E29.340BF74E.107@process.com> Subject: RE: Refresh TCPware host cache "Andy Williams" writes: > >Is there a way to force TCPware to re-read the HOSTS file immediately after >it's been edited ? We have an isolated test network that we're currently >adding systems to. Some of these systems are running in simulated live mode >so we can't stop & restart TCPware. However, if we edit the HOSTS file we've >noticed it can take up to about 10-15 minutes before the changes are picked >up... > By default, the TCPware_DNS process checks if it needs to reload the file every 10 minutes. You can change that default with the TCPWARE_RES_RELOAD_CHECK_INTVL logical. e.g. $ DEFINE/SYSTEM TCPWARE_RES_RELOAD_CHECK_INTVL "0 00:01:00" will change it to check if it needs to be reloaded every minute. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 30 Mar 1999 11:43:32 -0400 Message-ID: <3700FD6E.BA1F97A2@PROCESS.COM> Date: Tue, 30 Mar 1999 11:35:58 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: RE: Refresh TCPware host cache Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > >Is there a way to force TCPware to re-read the HOSTS file immediately after > >it's been edited ? We have an isolated test network that we're currently > >adding systems to. Some of these systems are running in simulated live mode > >so we can't stop & restart TCPware. However, if we edit the HOSTS file we've > >noticed it can take up to about 10-15 minutes before the changes are picked > >up... > > > > By default, the TCPware_DNS process checks if it needs to reload the > file every 10 minutes. > > You can change that default with the TCPWARE_RES_RELOAD_CHECK_INTVL > logical. > > e.g. > $ DEFINE/SYSTEM TCPWARE_RES_RELOAD_CHECK_INTVL "0 00:01:00" > > will change it to check if it needs to be reloaded every minute. > > You can 'force' a reload by shutting down the resolver and restarting it using the following commands - $ NETCU STOP/DNS $ @TCPWARE:START_RESOLVER DETACH While the resolver is down no host names, service names, or protocol names can be resolved. 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, 31 Mar 1999 07:32:52 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Correcting system time when using NTP Date: Wed, 31 Mar 1999 12:02:20 +0100 Message-ID: <7dsvb0$nte$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM Well, following on from the excellent responses to my last question here's another: In total we run close on 200 OpenVMS systems, mostly VAX V5.5-2 and V6.2 systems. We run TCPware V5.3-2 on around 60-65% of them (and climbing) and because we have a timefeed coming into our building we decided to use the NTP service wherever possible. This timefeed hits our systems as UTC irrespective of the time of year. When it came to resetting the time there didn't seem to be much information on exactly how to achieve this when NTP was running so I did some quick experiments. First off I just set the timezone to "+0100" to see if it would be picked up by NTPD next time it sampled the time servers but it appeared not to be. One hour after I'd changed the timezone the clock on my workstation hadn't been set forward. Following that I tried running NTPDATE but this requires the NTP daemon to be shut down. Eventually I created a DCL procedure that copied a file to the remote system. This file then basically did a SHUTNET NTP followed by NETCU SET TIMEZONE "+0100", then NTPDATE followed by a STARTNET NTP which seemed to do the trick. I can't help feeling there must be a more efficient way of doing it, though... This also raises the spectre of what happens when one of these systems crashes. The timezone is only held in memory so next time the system reboots it'll revert back to +0000 by default, and I don't really want to go editing that many TCPWARE_CONFIGURE files. Now, I found out about the ROUTING.COM file by pure accident (ie. I used TCPWARE_DEBUG just out of interest) so I've put some simple DCL logic in that to determine whether we're on summer time or not and set the timezone accordingly - but is that the right place for it ? I also tried to run NTPDATE in there following the timezone update but that managed to hang the TCPware startup. Why ? Because we use RIP with no default gateway. RIP appears to get enabled much further on in the startup, so NTPDATE couldn't see our time servers; unfortunately in this case it hangs, presumably waiting for them to appear... So, for my particular environment when an NTP-enabled system starts up it looks like to ensure the current time is exactly correct I need to do a STARTNET (including the zone-sensing ROUTING.COM) followed by a SHUTNET NTP, NTPDATE and STARTNET NTP. Of course the alternative is to not start the NTP daemon but use NTPDATE from a regularly-submitted batch job... Can I be doing all this more efficiently ? Are there any mechanisms that I could use anywhere to force TCPware to immediately validate/set the time once I've altered the timezone ? Thanks for any help ! -Andy ================================================================================ Archive-Date: Wed, 31 Mar 1999 09:34:47 -0400 From: "Andy Cheetham" Reply-To: Info-TCPware@process.com Subject: Re: Correcting system time when using NTP Date: Wed, 31 Mar 1999 14:35:28 +0100 Message-ID: <370224a2.0@nnrp1.news.uk.psi.net> To: Info-TCPware@PROCESS.COM Andy Williams wrote in message <7dsvb0$nte$1@gatekeeper.liffe.com>... >Can I be doing all this more efficiently ? Are there any mechanisms that I >could use anywhere to force TCPware to immediately validate/set the time >once I've altered the timezone ? > As far as I can see TCPWare has yet to catch up with the TDF capabilites of VMS 7.1. We are receiving the Rugby time signal on one of our VMS systems and using NTP to synch time on the others. TCPware was the only flaw in our plan as just described. I notice that there are a couple of other symbols set in TCPWARE_CONFIG.COM and a file in TCPWARE: called TIMEZONES.DAT that looks suspiciously like the same format as the SYS$TIME* logicals. Perhaps there is a way? Over to you Process... ================================================================================ Archive-Date: Wed, 31 Mar 1999 11:19:39 -0400 Message-ID: <37024952.EC2F73DE@PROCESS.COM> Date: Wed, 31 Mar 1999 11:12:02 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: Correcting system time when using NTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Well, following on from the excellent responses to my last question here's > another: > > In total we run close on 200 OpenVMS systems, mostly VAX V5.5-2 and V6.2 > systems. We run TCPware V5.3-2 on around 60-65% of them (and climbing) and > because we have a timefeed coming into our building we decided to use the > NTP service wherever possible. This timefeed hits our systems as UTC > irrespective of the time of year. When it came to resetting the time there > didn't seem to be much information on exactly how to achieve this when NTP > was running so I did some quick experiments. First off I just set the > timezone to "+0100" to see if it would be picked up by NTPD next time it > sampled the time servers but it appeared not to be. One hour after I'd > changed the timezone the clock on my workstation hadn't been set forward. > Following that I tried running NTPDATE but this requires the NTP daemon to > be shut down. Eventually I created a DCL procedure that copied a file to the > remote system. This file then basically did a SHUTNET NTP followed by NETCU > SET TIMEZONE "+0100", then NTPDATE followed by a STARTNET NTP which seemed > to do the trick. I can't help feeling there must be a more efficient way of > doing it, though... > > This also raises the spectre of what happens when one of these systems > crashes. The timezone is only held in memory so next time the system reboots > it'll revert back to +0000 by default, and I don't really want to go editing > that many TCPWARE_CONFIGURE files. Now, I found out about the ROUTING.COM > file by pure accident (ie. I used TCPWARE_DEBUG just out of interest) so > I've put some simple DCL logic in that to determine whether we're on summer > time or not and set the timezone accordingly - but is that the right place > for it ? I also tried to run NTPDATE in there following the timezone update > but that managed to hang the TCPware startup. Why ? Because we use RIP with > no default gateway. RIP appears to get enabled much further on in the > startup, so NTPDATE couldn't see our time servers; unfortunately in this > case it hangs, presumably waiting for them to appear... > > So, for my particular environment when an NTP-enabled system starts up it > looks like to ensure the current time is exactly correct I need to do a > STARTNET (including the zone-sensing ROUTING.COM) followed by a SHUTNET NTP, > NTPDATE and STARTNET NTP. Of course the alternative is to not start the NTP > daemon but use NTPDATE from a regularly-submitted batch job... > > Can I be doing all this more efficiently ? Are there any mechanisms that I > could use anywhere to force TCPware to immediately validate/set the time > once I've altered the timezone ? > Andy, What version of TCPware are you using? TCPware version 5.3-3 added Daylight Savings Time support so NTP can automatically change the OpenVMS system time when DST time begins or ends. It did not make the 5.3 documentation but is in the 5.3-3 release notes. 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, 31 Mar 1999 12:07:01 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Re: Correcting system time when using NTP Date: Wed, 31 Mar 1999 17:50:16 +0100 Message-ID: <7dtjna$h5p$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM We're standardising on V5.3-2 for entering next year (I can't bring myself to call it the "new millennium when it isn't). Unfortunately there's little or no chance we'll be allowed to upgrade because of the amount of testing work it would place on our application developers; they've got a big backlog already...although I could put it onto my workstation & watch it go through a couple of timechanges. Apart from that, our TCPware supplier here in the UK has yet to tell us that V5.5-3 exists... Is it a full-blown release or effectively a patch on top of V5.3-2 ? If it's only a patch I could maybe download it. That aside, it sounds like there's nothing more I can do under V5.3-2... Cheers, -Andy > >Andy, > > What version of TCPware are you using? TCPware version 5.3-3 added >Daylight Savings Time support so NTP can automatically change the OpenVMS >system time when DST time begins or ends. It did not make the 5.3 documentation >but is in the 5.3-3 release notes. > >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, 31 Mar 1999 12:41:45 -0400 Message-ID: <37025C8F.22540F8A@PROCESS.COM> Date: Wed, 31 Mar 1999 12:34:07 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: re: Correcting system time when using NTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > We're standardising on V5.3-2 for entering next year (I can't bring myself > to call it the "new millennium when it isn't). > Unfortunately there's little or no chance we'll be allowed to upgrade > because of the amount of > testing work it would place on our application developers; they've got a big > backlog already...although I could put it onto > my workstation & watch it go through a couple of timechanges. > > Apart from that, our TCPware supplier here in the UK has yet to tell us that > V5.5-3 exists... Is it a full-blown release or effectively a patch on top of > V5.3-2 ? If it's only a patch I could maybe download it. 5.3-3 is a full kit that included fixes made to 5.3-2 and also added the DST support and support for pseudo interfaces. I'm not sure if that helps you or not. > > That aside, it sounds like there's nothing more I can do under V5.3-2... I can't think of any other ideas besides what you've come up with. 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, 31 Mar 1999 15:41:40 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: re: Correcting system time when using NTP Date: 31 Mar 1999 22:28:42 +0100 Message-ID: <3702857a.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <37025C8F.22540F8A@PROCESS.COM>, Michael Corbett writes: > 5.3-3 is a full kit that included fixes made to 5.3-2 and also >added the DST support and support for pseudo interfaces. I think, this is exactly the problem. (Almost ?) Nobody expects new features in a "maintenance" version. Especially, when the local distributor "never heard of V5.3-3 before" and you as a customer will not receive such a maint version automatically... To say something good: I've had no problems downloading the V5.3-3 (with the help of Process Support) from the Process FTP server. Thanks folks. With direct PSC support I was able to get V5.3-3 (in Aug-98), months before our local distributor even heard of V5.3-3 (by me)... ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Wed, 31 Mar 1999 16:02:34 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B555@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Correcting system time when using NTP Date: Wed, 31 Mar 1999 21:57:29 +0100 MIME-Version: 1.0 Content-Type: text/plain Andy, We're in the UK, (Jersey), and are evaluating TCPware at the moment, and are likely to buy it for at least one development system and a production cluster. Where do you get support from ? I've been dealing with Allasso (Integralis), but seem to have had much better support from people like Hunter on the tcpware mailing list than I have from Allasso/Integralis. Regards, Derek... > -----Original Message----- > From: Andy Williams [SMTP:Andy.Williams@LIFFE.COM] > Sent: 31 March 1999 17:50 > To: Info-TCPware@PROCESS.COM > Subject: Re: Correcting system time when using NTP > > We're standardising on V5.3-2 for entering next year (I can't bring > myself > to call it the "new millennium when it isn't). > Unfortunately there's little or no chance we'll be allowed to upgrade > because of the amount of > testing work it would place on our application developers; they've got > a big > backlog already...although I could put it onto > my workstation & watch it go through a couple of timechanges. > > Apart from that, our TCPware supplier here in the UK has yet to tell > us that > V5.5-3 exists... Is it a full-blown release or effectively a patch on > top of > V5.3-2 ? If it's only a patch I could maybe download it. > > That aside, it sounds like there's nothing more I can do under > V5.3-2... > > Cheers, > > -Andy > > > > >Andy, > > > > What version of TCPware are you using? TCPware version 5.3-3 added > >Daylight Savings Time support so NTP can automatically change the > OpenVMS > >system time when DST time begins or ends. It did not make the 5.3 > documentation > >but is in the 5.3-3 release notes. > > > >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 > > > *********************************************************************** 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 dissemination, distribution or copying is strictly prohibited. If you have received this message in error please delete it immediately and advise us by return e-mail. *********************************************************************** ================================================================================ Archive-Date: Wed, 31 Mar 1999 16:04:14 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B556@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Correcting system time when using NTP Date: Wed, 31 Mar 1999 21:59:14 +0100 MIME-Version: 1.0 Content-Type: text/plain There does seem to be some strange issues with distributors. We received an evaluation kit from our distributor in the UK a couple of weeks ago, and it was 5.3-2. Derek... > -----Original Message----- > From: eplan@kapsch.net [SMTP:eplan@kapsch.net] > Sent: 31 March 1999 22:29 > To: Info-TCPware@PROCESS.COM > Subject: re: Correcting system time when using NTP > > In article <37025C8F.22540F8A@PROCESS.COM>, Michael Corbett > writes: > > 5.3-3 is a full kit that included fixes made to 5.3-2 and also > >added the DST support and support for pseudo interfaces. > > I think, this is exactly the problem. > > (Almost ?) Nobody expects new features in a "maintenance" version. > Especially, when the local distributor "never heard of V5.3-3 before" > and you as a customer will not receive such a maint version > automatically... > > To say something good: I've had no problems downloading the V5.3-3 > (with the help of Process Support) from the Process FTP server. Thanks > folks. > With direct PSC support I was able to get V5.3-3 (in Aug-98), months > before > our local distributor even heard of V5.3-3 (by me)... > > ---------------------------------------------------------------------- > -- > 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 *********************************************************************** 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 dissemination, distribution or copying is strictly prohibited. If you have received this message in error please delete it immediately and advise us by return e-mail. *********************************************************************** ================================================================================ Archive-Date: Wed, 31 Mar 1999 16:17:00 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B558@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Correcting system time when using NTP Date: Wed, 31 Mar 1999 22:11:55 +0100 MIME-Version: 1.0 Content-Type: text/plain Oops - this was meant to be a private email to Andy. > -----Original Message----- > From: Derek Fage [SMTP:Derekf@ITEXJSY.com] > Sent: 31 March 1999 21:57 > To: 'Info-TCPware@process.com' > Subject: RE: Correcting system time when using NTP > > Andy, > > We're in the UK, (Jersey), and are evaluating TCPware at the moment, > and > are likely to buy it for at least one development system and a > production cluster. > > Where do you get support from ? I've been dealing with Allasso > (Integralis), but seem to have had much better support from people > like > Hunter on the tcpware mailing list than I have from > Allasso/Integralis. > > Regards, > > Derek... > > > -----Original Message----- > > From: Andy Williams [SMTP:Andy.Williams@LIFFE.COM] > > Sent: 31 March 1999 17:50 > > To: Info-TCPware@PROCESS.COM > > Subject: Re: Correcting system time when using NTP > > > > We're standardising on V5.3-2 for entering next year (I can't bring > > myself > > to call it the "new millennium when it isn't). > > Unfortunately there's little or no chance we'll be allowed to > upgrade > > because of the amount of > > testing work it would place on our application developers; they've > got > > a big > > backlog already...although I could put it onto > > my workstation & watch it go through a couple of timechanges. > > > > Apart from that, our TCPware supplier here in the UK has yet to tell > > us that > > V5.5-3 exists... Is it a full-blown release or effectively a patch > on > > top of > > V5.3-2 ? If it's only a patch I could maybe download it. > > > > That aside, it sounds like there's nothing more I can do under > > V5.3-2... > > > > Cheers, > > > > -Andy > > > > > > > >Andy, > > > > > > What version of TCPware are you using? TCPware version 5.3-3 > added > > >Daylight Savings Time support so NTP can automatically change the > > OpenVMS > > >system time when DST time begins or ends. It did not make the 5.3 > > documentation > > >but is in the 5.3-3 release notes. > > > > > >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 > > > > > > > ********************************************************************** > * > 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 > dissemination, distribution or copying is strictly prohibited. If you > have received this message in error please delete it immediately and > advise us by return e-mail. > ********************************************************************** > * *********************************************************************** 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 dissemination, distribution or copying is strictly prohibited. If you have received this message in error please delete it immediately and advise us by return e-mail. *********************************************************************** ================================================================================ Archive-Date: Wed, 31 Mar 1999 16:48:24 -0400 Message-ID: <3702965B.E667FE9C@PROCESS.COM> Date: Wed, 31 Mar 1999 16:40:43 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: re: Correcting system time when using NTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > In article <37025C8F.22540F8A@PROCESS.COM>, Michael Corbett writes: > > > > 5.3-3 is a full kit that included fixes made to 5.3-2 and also > >added the DST support and support for pseudo interfaces. > > I think, this is exactly the problem. > > (Almost ?) Nobody expects new features in a "maintenance" version. > Especially, when the local distributor "never heard of V5.3-3 before" > and you as a customer will not receive such a maint version automatically... Looking at it in hindsight 5.3-3 probably should not have been a maintenance release and probably should have been TCPware 5.4. Lesson learned... > > To say something good: I've had no problems downloading the V5.3-3 > (with the help of Process Support) from the Process FTP server. Thanks folks. > With direct PSC support I was able to get V5.3-3 (in Aug-98), months before > our local distributor even heard of V5.3-3 (by me)... The distributors should have known about 5.3-3 when it was released and we'll make sure that there are better communications between us and our distributors in the future to avoid this. 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, 31 Mar 1999 18:05:32 -0400 Subject: Re: Correcting system time when using NTP Message-ID: <1999Mar31.174222@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 31 Mar 99 17:42:22 -0500 To: Info-TCPware@PROCESS.COM In response for those that are running versions of TCPware before DTS support was introduced ... Here's a repost of an earlier posting I did: ** The following is unsupported and provided for informational purposes only. What we've done here is fairly simple. TCPWARE_CONFIGURE.COM should define the standard timezone (EST, for example). In ROUTING.COM, invoke another command procedure called "TIMEZONE.COM" or something like that. TIMEZONE.COM would be: $ SET NOON $! $! Do standard/daylight savings time fixups $! $ DAY_Sunday = 0 $ DAY_Monday = 6 $ DAY_Tuesday = 5 $ DAY_Wednesday = 4 $ DAY_Thursday = 3 $ DAY_Friday = 2 $ DAY_Saturday = 1 $ TEMPN = DAY_'F$CVTIME("01-APR",,"WEEKDAY")' + 1 $ ST = F$CVTIME("''TEMPN'-APR:02:00:00") $ DAY_Sunday = 0 $ DAY_Monday = 1 $ DAY_Tuesday = 2 $ DAY_Wednesday = 3 $ DAY_Thursday = 4 $ DAY_Friday = 5 $ DAY_Saturday = 6 $ TEMPN = 31 - DAY_'F$CVTIME("31-OCT",,"WEEKDAY")' $ ET = F$CVTIME("''TEMPN'-OCT:02:00:00") $ CT = F$CVTIME() $ TIME = "STANDARD" $ IF ((CT .GES. ST) .AND. (CT .LTS. ET)) THEN TIME = "DAYLIGHT" $ IF (TIME .EQS. "STANDARD") THEN TIMEZONE = "-0500" $ IF (TIME .EQS. "DAYLIGHT") THEN TIMEZONE = "-0400" $ ENDIF $ NETCU SET TIMEZONE 'TIMEZONE' $! End of configuration file Of course, you need to change the following two lines based on your timezone: $ IF (TIME .EQS. "STANDARD") THEN TIMEZONE = "-0500" $ IF (TIME .EQS. "DAYLIGHT") THEN TIMEZONE = "-0400" Note that the procedure follows the rules for the United States. If your timezone follows different rules, you'll need to adjust the logic. The above will set the proper value at TCPware start-up time. That leaves applying the timezone change when it happens. That is done by another batch job. We happen to run this every day to keep all the clocks in the cluster in reasonable sync and it is as follows: $ SET NOON $! $ DAY_Sunday = 0 $ DAY_Monday = 6 $ DAY_Tuesday = 5 $ DAY_Wednesday = 4 $ DAY_Thursday = 3 $ DAY_Friday = 2 $ DAY_Saturday = 1 $ TEMPN = DAY_'F$CVTIME("01-APR",,"WEEKDAY")' + 1 $ ST = F$CVTIME("''TEMPN'-APR:02:00:00") $ DAY_Sunday = 0 $ DAY_Monday = 1 $ DAY_Tuesday = 2 $ DAY_Wednesday = 3 $ DAY_Thursday = 4 $ DAY_Friday = 5 $ DAY_Saturday = 6 $ TEMPN = 31 - DAY_'F$CVTIME("31-OCT",,"WEEKDAY")' $ ET = F$CVTIME("''TEMPN'-OCT:02:00:00") $ CT = F$CVTIME() $ TIMEZONE = "EST" $ IF ((CT .GES. ST) .AND. (CT .LTS. ET)) THEN TIMEZONE = "EDT" $ IF (P1 .EQS. "") THEN P1 = TIMEZONE $ IF (TIMEZONE .EQS. P1) THEN GOTO NO_TIMEZONE_CHANGE $ P1 = TIMEZONE $ DELTA_TIME = "-01:00:00.00" ! Change to EST $ IF (TIMEZONE .EQS. "EDT") THEN DELTA_TIME = "+01:00:00.00" ! Change to EDT $ SET TIME="''DELTA_TIME'"/CLUSTER $! Now fix up TCPware items as well $ UT_OFFSET = "-0500" $ IF (TIMEZONE .EQS. "EDT") THEN UT_OFFSET = "-0400" $ OPEN/WRITE TZFIXUPS SYS$COMMON:[SYSMGR]00TEMPTZ.COM $ WRITE TZFIXUPS "$ SET NOON" $ WRITE TZFIXUPS "$ NETCU :== $TCPWARE:NETCU" $ WRITE TZFIXUPS "$ NETCU SET TIMEZONE ''UT_OFFSET'" $ WRITE TZFIXUPS "$ DEFINE/SYSTEM/EXEC NEWS_TIMEZONE ''UT_OFFSET'" $ CLOSE TZFIXUPS $ FILE = F$SEARCH("SYS$COMMON:[SYSMGR]00TEMPTZ.COM") $ OPEN/WRITE SYSFIL SYS$COMMON:[SYSMGR]00TEMPTZ1.COM $ WRITE SYSFIL "$ MCR SYSMAN" $ WRITE SYSFIL " SET ENVIRONMENT/CLUSTER" $ WRITE SYSFIL " DO @''FILE'" $ CLOSE SYSFIL $ @SYS$COMMON:[SYSMGR]00TEMPTZ1.COM $ DELETE/NOLOG SYS$COMMON:[SYSMGR]00TEMPTZ1.COM;* $ DELETE 'FILE'/NOLOG $! $NO_TIMEZONE_CHANGE: $ SET TIME="+00:00:00.00"/CLUSTER $! $ SCSNODE = F$EDIT(F$GETSYI("SCSNODE"),"COLLAPSE") $ SUBMIT/NOPRINT/NOLOG/RESTART/AFTER="TOMORROW:+02:00:00" - /QUE=SYS$BATCH$'SCSNODE'/PARAM="''P1'" SYS$MANAGER:TIMEKEEPER You'll have to play with this one a bit to customize it to your needs and timezone. That's left as an exercise for the reader (search for EST and EDT, and -04 and -05). The first time the batch job is run, there will be no P1 so it will assume not to adjust the clock/timezone. NOTE: It also changes the clock on the system (cluster) so beware! Don't send me requests regarding this stuff. It is provided "AS IS" and beware that you'll need to customize it (it was written for our specific needs). It has worked great for many years for us. - Bernie Volz Process Software