Archive-Date: Thu, 1 Apr 1999 03:22:40 -0400 Date: Thu, 01 Apr 1999 09:15:10 +0100 From: "Raymond, David" Reply-To: Info-TCPware@process.com Subject: RE: Correcting system time when using NTP To: "'Info-TCPware@process.com'" CC: Q-Process Message-ID: <90088CB087DBD21194870008C733B45D048B46@NTESS005> MIME-Version: 1.0 Content-Type: text/plain Andy, FYI, we has a lot of trouble ourselves finding the status of 5.3-3. The position is that it is a 'maintenance' release which is available on request. It was never 'announced' by Process as such. It's a pity all round that Process did not make it a full release! If you want a copy, let me know! Regards David >-----Original Message----- >From: Andy Williams [mailto: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 > > > > > ================================================================================ Archive-Date: Thu, 1 Apr 1999 04:03:57 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: re: Correcting system time when using NTP Date: 1 Apr 1999 10:51:54 +0100 Message-ID: <370333aa.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <3702965B.E667FE9C@PROCESS.COM>, Michael Corbett writes: > 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... Thanks Michael for answering. This is nice to hear/read, but may I add 2 another hints: *) With only a few (you mentioned only 2) new features, this shouldn't be a new version of TCPware either. Keep this new features and add some more (eg. the already mentioned new DHCP server of V5.4, maybe a RADIUS server, a SYSLOG server, some prebuilt SNMP subagents for system-mgmt, NSAP and NSAP-PTR RR in BIND/DNS, more built in debugging support - enabled via documented logicals, ...) and if the time is right then build/offer a new full distribution version, which means, CD-Kit (or Tape-Kit) for Software and new manuals in paper and on CD. *) A Maint version is IMHO good and required, but as a replacement of a lot of patches to the base version (a "master" patch). And this maint version should be only an "upgrade" kit (and not a full blown distribution). Then, offering this maint kit on FTP/WWW should be no problem (versus offering a full distribution kit on FTP/WWW for all customers _is_ a problem) and should be the 'standard' way to get the kits to the user (and the distributor). And documentation is of course only the readme/release-notes of this maint version. The distributor is still required for customers without an Internet Link (there are a still a lot of them, but maybe they are not TCPware customers). >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. Life with TCPware (and PSC) was so much easier, until PSC had to reorganize itself some years ago (was the aquisition of Multinet the reason ?)... 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: Thu, 1 Apr 1999 07:04:19 -0400 From: "Andy Cheetham" Reply-To: Info-TCPware@process.com Subject: Re: Correcting system time when using NTP Date: Thu, 1 Apr 1999 12:55:19 +0100 Message-ID: <37035ea9.0@nnrp1.news.uk.psi.net> To: Info-TCPware@PROCESS.COM >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. > Michael Ok so how do I set it up? Here's what I've got set-up at the moment... "SYS$TIMEZONE_DAYLIGHT_SAVING" = "1" "SYS$TIMEZONE_DIFFERENTIAL" = "3600" "SYS$TIMEZONE_NAME" = "BST" "SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.5.0/1,M10.4.0/1" "TCPWARE_TIMEZONE" = "+010000" = "BST" ================================================================================ Archive-Date: Thu, 1 Apr 1999 07:33:10 -0400 From: "Andy Cheetham" Reply-To: Info-TCPware@process.com Subject: Re: Correcting system time when using NTP Date: Thu, 1 Apr 1999 12:43:16 +0100 Message-ID: <37035bd6.0@nnrp1.news.uk.psi.net> To: Info-TCPware@PROCESS.COM >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. > We are running v5.3-3 I'll have a look in the release notes - Thanks for the suggestion! Andy ================================================================================ Archive-Date: Thu, 1 Apr 1999 09:26:20 -0400 Sender: goatley@triton.process.com Return-Path: From: samson@iohk.com (Samson Luk) Reply-To: Info-TCPware@process.com Subject: VPN Product for OpenVMS/TCPWARE Date: Thu, 01 Apr 1999 02:41:47 GMT Message-ID: <8E019E0AEC4E3BB3.50ED744F06614476.6F99650D6D83A83E@library-proxy.airnews.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Any recommendation? ================================================================================ Archive-Date: Thu, 1 Apr 1999 11:29:46 -0400 Message-ID: <37039D55.DA4020AA@PROCESS.COM> Date: Thu, 01 Apr 1999 11:22:45 -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 <3702965B.E667FE9C@PROCESS.COM>, Michael Corbett writes: > > 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... > > Thanks Michael for answering. > This is nice to hear/read, but may I add 2 another hints: Always open to suggestions... > > *) With only a few (you mentioned only 2) new features, this shouldn't > be a new version of TCPware either. Keep this new features and add > some more (eg. the already mentioned new DHCP server of V5.4, maybe a > RADIUS server, a SYSLOG server, some prebuilt SNMP subagents for > system-mgmt, NSAP and NSAP-PTR RR in BIND/DNS, more built in debugging > support - enabled via documented logicals, ...) and if the time is > right then build/offer a new full distribution version, which means, > CD-Kit (or Tape-Kit) for Software and new manuals in paper and on CD. You're right. A new version should contain a few significant new features, which was why we made 5.3-3 a maintenance release and not TCPware 5.4 It did have some new features which broke the 'no new features' in a maintenance release practice. We had the new features ready, felt they were important and had customers that were waiting for them so we decided to put them in 5.3-3 rather than waiting until we felt there were enough new features to call it TCPware 5.4. Again, in hindsight this might not have been the best thing to do. > > *) A Maint version is IMHO good and required, but as a replacement of > a lot of patches to the base version (a "master" patch). And this > maint version should be only an "upgrade" kit (and not a full blown > distribution). Then, offering this maint kit on FTP/WWW should be no > problem (versus offering a full distribution kit on FTP/WWW for all > customers _is_ a problem) and should be the 'standard' way to get the > kits to the user (and the distributor). And documentation is of course > only the readme/release-notes of this maint version. I don't think we will offer 'upgrade' releases, each release will be a full kit that will either upgrade or install the full product. The difference between a maintenance release and a version release would be that the maintenance release would not include any substantial new features and would just be the previous release plus all available fixes and patches. A maintenance release would not include new documentation just release notes. This would allow customers currently running the release to just install the maintenance release to get the latest fixes without worrying about major changes and also allow new customers to install the maintenance release only and not the version release and the maintenance release. We do offer all the releases on CD or tape, and via FTP and WWW so if getting the maintenance release via the internet is not an option for a particular customer they can request it be shipped to them. > > >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. > > Life with TCPware (and PSC) was so much easier, until PSC had to reorganize > itself some years ago (was the aquisition of Multinet the reason ?)... > I think the acquisition of Multinet might have caused some growing pains but I think we've got by them now. Let us know what we can do to improve and we'll see if we can make it easy again. 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, 1 Apr 1999 13:32:50 -0400 Message-ID: <3C2625E7CCB3D211A331AA000400710501E728@omlnt1.omlabs.com> From: "Bruce, Michael" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Correcting system time when using NTP Date: Thu, 1 Apr 1999 10:25:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I'm running tcpware v5.3-2 and between your command file and the documenation I am not clear on exactly what is occurring during a time change while running NTP. I'm I correct in understanding that for the time change (standard/daylight) I need to set the system time with a SET TIME=/CLUSTER command and then follow that with a NETCU SET TIMEZONE command? What does NTP do if I only do the NETCU SET TIMEZONE command or only do the SET TIME=/CLUSTER command? Michael Bruce Systems Manager Oregon Medical Labs TEL: 541.984.8296 FAX: 541.465.3337 E-Mail: Michael.Bruce@altavista.net -----Original Message----- From: volz@process.com [mailto:volz@process.com] Sent: Wednesday, March 31, 1999 2:42 PM To: Info-TCPware@PROCESS.COM Subject: Re: Correcting system time when using NTP 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 ================================================================================ Archive-Date: Thu, 1 Apr 1999 17:07:08 -0400 Subject: Re: Correcting system time when using NTP Message-ID: <1999Apr1.160750@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Apr 99 16:07:50 -0500 To: Info-TCPware@PROCESS.COM In article <7dvdk5$nq6$1@gatekeeper.liffe.com>, "Andy Williams" writes: > Bernie, > > Thanks for the response; it's pretty much exactly what I implemented last > night. I created a ROUTING.COM that susses out what timezone we're supposed > to be set to and which is also capable of being called as a standalone batch > job. Within the system startup procedure I've added a SHUTNET NTP, NTPDATE, > STARTNET NTP sequence to ensure the date/time is OK at system startup. A > batch job runs ROUTING.COM every Sunday in the early hours to determine > whether the timezone needs to shift. > > The only other question I'd ask is whether it's possible to force a > timechange through without shutting NTP down, running NTPDATE and then > restarting ? In other words, the "batch job" ROUTING.COM has run at 02:00 > or whatever & decided to shift timezone. Just doing a NETCU SET TIMEZ > "+0100" doesn't seem to prod NTPD into doing the necessary "corrective" > action in any kind of hurry... > > Cheers, > > -Andy Hum ... I'm not an NTP expert but I believe you have do NOTHING more. NTP reads the timezone logical periodically. There is also a comment in the source code that reads "Timezone may change during operation, going on or off DST, this will normally trigger our clock shift sanity check." The sanity check will re-read the timezone. I guess the proof will be this weekend. - Bernie Volz ================================================================================ Archive-Date: Thu, 1 Apr 1999 17:07:12 -0400 Subject: RE: Correcting system time when using NTP Message-ID: <1999Apr1.161407@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Apr 99 16:14:07 -0500 To: Info-TCPware@PROCESS.COM In article <3C2625E7CCB3D211A331AA000400710501E728@omlnt1.omlabs.com>, "Bruce, Michael" writes: > I'm running tcpware v5.3-2 and between your command file and the > documenation I am not clear on exactly what is occurring during a time > change while running NTP. > > I'm I correct in understanding that for the time change (standard/daylight) > I need to set the system time with a SET TIME=/CLUSTER command and then > follow that with a NETCU SET TIMEZONE command? What does NTP do if I only > do the NETCU SET TIMEZONE command or only do the SET TIME=/CLUSTER command? > > Michael Bruce > Systems Manager > Oregon Medical Labs > TEL: 541.984.8296 > FAX: 541.465.3337 > E-Mail: Michael.Bruce@altavista.net Just answered some this in the my post a few moments ago. Hum ... I'm not an NTP expert but I believe you have do NOTHING more. NTP reads the timezone logical periodically. There is also a comment in the source code that reads "Timezone may change during operation, going on or off DST, this will normally trigger our clock shift sanity check." The sanity check will re-read the timezone. I guess the proof will be this weekend. If you don't change the cluster time, I'd assume NTP would slowly correct it. However, I'd recommend adjust the time. You need not do /CLUSTER if you don't want to, but do a SET TIME=+01:00:00 or SET TIME=-01:00:00 on each system. See the "Troubleshooting Tips" in the NTP chapter - it strongly recommends making sure the time is "near" the real time because NTP is best used when that is the case. If large time changes cause you problems, I'm not sure what the best solution is. Perhaps let NTP adjust it? - Bernie Volz ================================================================================ Archive-Date: Fri, 2 Apr 1999 05:13:46 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Re: Correcting system time when using NTP Date: Thu, 1 Apr 1999 10:18:34 +0100 Message-ID: <7dvdk5$nq6$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM Bernie, Thanks for the response; it's pretty much exactly what I implemented last night. I created a ROUTING.COM that susses out what timezone we're supposed to be set to and which is also capable of being called as a standalone batch job. Within the system startup procedure I've added a SHUTNET NTP, NTPDATE, STARTNET NTP sequence to ensure the date/time is OK at system startup. A batch job runs ROUTING.COM every Sunday in the early hours to determine whether the timezone needs to shift. The only other question I'd ask is whether it's possible to force a timechange through without shutting NTP down, running NTPDATE and then restarting ? In other words, the "batch job" ROUTING.COM has run at 02:00 or whatever & decided to shift timezone. Just doing a NETCU SET TIMEZ "+0100" doesn't seem to prod NTPD into doing the necessary "corrective" action in any kind of hurry... Cheers, -Andy Bernie Volz wrote in message <1999Mar31.174222@alcor.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). > >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 ================================================================================ Archive-Date: Sat, 3 Apr 1999 01:35:59 -0400 From: peter.burnett@tnx.neverlnd.org.uk (Peter Burnett) Reply-To: Info-TCPware@process.com Subject: Correcting system time when using NTP Date: 02 Apr 99 23:57:21 GMT Message-ID: <786_9904030701@neverlnd.org.uk> To: Info-TCPware@PROCESS.COM Wednesday March 31 1999, Derekf@ITEXJSY.com writes to All: D> Where do you get support from ? I've been dealing with Allasso D> (Integralis), but seem to have had much better support from people like D> Hunter on the tcpware mailing list than I have from Allasso/Integralis. Tell me about it,,,,, They seem quick enough to sell you a license but when it comes to support.... enuff said !!!!.... I have suggested that maybe Process should perform an audit check on thier 3rd party agents. Peter - pdb@post.neverlnd.org.uk - http://www.neverlnd.demon.co.uk ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- +-------------------------------------------------------------------------+ | Data: 44-(0)1424-853361 Fax: 44-(0)1424-853364 Hastings | |Voice: 44-(0)468-817347 ISDN: 44-(0)1424-854816 East Sussex | | pdb@post.neverlnd.org.uk UK | +---------------( Http://www.neverlnd.demon.co.uk )-----------------------+ ================================================================================ Archive-Date: Sun, 4 Apr 1999 11:41:33 -0400 From: "WK" Reply-To: Info-TCPware@process.com Subject: Same time on different machines Date: Sun, 4 Apr 1999 18:32:53 +0200 Sender: wimmy@dc2-isdn1891.dial.xs4all.nl Message-ID: <7e846i$shp$1@news2.xs4all.nl> To: Info-TCPware@PROCESS.COM We have at our office 5 clusters ( VAX and ALPHA ) and we have about 20 standalone systems ( microvaxes etc etc ) But what would be the best way to synchronize all the system times at the same time. I think it could be done with SYSMAN, but I dont know how to set it up, it keeps asking for a password is I say set envirionment VAXA for example if I'm on node VAXB and my username and password are the same, and I think it takes about 1 or 2 minutes to do this. I have heard about NTP would that be a solution for me. I hope that someone can help me out, we are using tcpware for IP connections. Thanks in advance WIm ================================================================================ Archive-Date: Mon, 5 Apr 1999 09:47:09 -0400 Sender: DLUTES@textron.com Message-ID: <37087877.A5E38BE@cessna.textron.com> Date: Mon, 05 Apr 1999 08:46:47 -0500 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Same time on different machines References: <7e846i$shp$1@news2.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit WK wrote: > We have at our office 5 clusters ( VAX and ALPHA ) and we have about 20 > standalone systems ( microvaxes etc etc ) > But what would be the best way to synchronize all the system times at the > same time. > I think it could be done with SYSMAN, but I dont know how to set it up, it > keeps asking for a password is I say set envirionment VAXA for example if > I'm on node VAXB and my username and password are the same, and I think it > takes about 1 or 2 minutes to do this. Here's how you might do it with SYSMAN alone. This example comes from the SYSMAN's HELP CONFIGURATION SET TIME command. As a result of slight inaccuracies in each processor clock, times on various members of a cluster tend to drift apart. The following procedure synchronizes system times in a cluster environment: $ SYNCH_CLOCKS: $ RUN SYS$SYSTEM:SYSMAN SET ENVIRONMENT/CLUSTER CONFIGURATION SET TIME EXIT $ WAIT 6:00:00 $ GOTO SYNCH_CLOCKS The procedure sets the time on all cluster nodes to the value obtained from the local time-of-year clock, waits 6 hours, then resets the time for the cluster. I do something similar with a batch job that executes every morning at 1:00am rather than every 6 hours. In regards to SYSMAN asking you for a password: I am guessing that VAXA and VAXB are not clustered. Do you have DECnet proxy access enabled between the two machines? Dale ================================================================================ Archive-Date: Mon, 5 Apr 1999 12:04:05 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B56B@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: Purveyor being dumped ? Date: Mon, 5 Apr 1999 17:06:24 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, I just received this email, and wanted to see if anybody from Process could give an indication as to where Purveyor stands as regards on-going development and support. Regards, Derek... > -----Original Message----- > From: Ed Wilts [SMTP:ewilts@winternet.com] > Sent: 03 April 1999 21:11 > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Anybody using PURVEYOR by Process Software? > > Victor P. Dura wrote: > > > We are beginning an evaluation of PURVEYOR web server software on > our > > VAX. We have less than 30-days to do this while maintaining a > > continued high level of excellent service to our users :), so we > won't > > be able to do as thorough an evaluation as I would like. > > > > Consequently, I was wondering if any of you out there have any > > comments about Purveyor? Good or bad, pro or con, I would be > > interested in reading your comments. > > Purveyor is an excellent product, but you should be aware that it's > also > a dead-end product. I was told by Process Software that I need not > bother paying for maintenance since there is no more development, and > it's been a long time since they even did a bug-fix release. When I > bought the product last year, the CD I received didn't even have the > latest patch kits on it, so be sure to contact them about getting a > patch > right away. > > Again, it's a darn fine product, and we'll continue using it, but > don't > expect a long-term commitment by Process. > > .../Ed > mailto:ewilts@winternet.com > *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Mon, 5 Apr 1999 14:27:04 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86010BE19C@lespaul.process.com> From: Lauren Maschio Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor being dumped ? Date: Mon, 5 Apr 1999 14:27:43 -0400 MIME-Version: 1.0 Content-Type: text/plain Process Software has not made an official statement to its Purveyor customer-base about the status of this product. However, an official notice will be sent to our customers shortly which will address Purveyor's future. Currently, Process Software has been telling customers that Purveyor is being sold on an as is basis and that there is no planned product development. Process Software is still supporting the product, but the support for Purveyor will be phased-out, meaning no new support contracts are being sold and the existing support contracts will be honored through expiration, but will not be renewed. Lauren Maschio Senior Product Manager -----Original Message----- From: Derek Fage [mailto:Derekf@ITEXJSY.com] Sent: Monday, April 05, 1999 12:06 PM To: Info-TCPware@PROCESS.COM Subject: Purveyor being dumped ? Hi there, I just received this email, and wanted to see if anybody from Process could give an indication as to where Purveyor stands as regards on-going development and support. Regards, Derek... > -----Original Message----- > From: Ed Wilts [SMTP:ewilts@winternet.com] > Sent: 03 April 1999 21:11 > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Anybody using PURVEYOR by Process Software? > > Victor P. Dura wrote: > > > We are beginning an evaluation of PURVEYOR web server software on > our > > VAX. We have less than 30-days to do this while maintaining a > > continued high level of excellent service to our users :), so we > won't > > be able to do as thorough an evaluation as I would like. > > > > Consequently, I was wondering if any of you out there have any > > comments about Purveyor? Good or bad, pro or con, I would be > > interested in reading your comments. > > Purveyor is an excellent product, but you should be aware that it's > also > a dead-end product. I was told by Process Software that I need not > bother paying for maintenance since there is no more development, and > it's been a long time since they even did a bug-fix release. When I > bought the product last year, the CD I received didn't even have the > latest patch kits on it, so be sure to contact them about getting a > patch > right away. > > Again, it's a darn fine product, and we'll continue using it, but > don't > expect a long-term commitment by Process. > > .../Ed > mailto:ewilts@winternet.com > *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Tue, 6 Apr 1999 05:14:43 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B576@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: GATED OPCOM Warning Messages Date: Tue, 6 Apr 1999 10:17:09 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, We are in a transitory situation where we have multiple routers running OSPF in defferent logical subnets on the same physical network. (We hope to resolve this in the next month or so as we migrate to VLANs). In the meantime, is there any way I can configure TCPware or GATED as to what messages to send to OPCOM (or at least to stop sending these particular messages). %%%%%%%%%%% OPCOM 6-APR-1999 10:08:03.03 %%%%%%%%%%% Message from user SYSTEM on EXTEL %TCPWARE_GATED-W-WARNING, OSPF RECV 189.1.254.254 -> 224.0.0.5: IP: bad destination As a secondary issue, has anybody got any of the commands working that use OSPF_DESTS.DAT ? The documentation is a bit lacking in this area. With the OSPF_DESTS.DAT, should the IP address be the IP address that the broadcasts are coming from, or the OSPF router ID ? Should the local server be specified in here ? Regards, Derek... *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Tue, 6 Apr 1999 09:27:10 -0400 Sender: bryant@process.com Date: Tue, 6 Apr 1999 09:27:52 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D6398.35606AED.3@process.com> Subject: RE: GATED OPCOM Warning Messages Derek Fage writes: > >Hi there, > >We are in a transitory situation where we have multiple routers running >OSPF in defferent logical subnets on the same physical network. (We hope >to resolve this in the next month or so as we migrate to VLANs). > >In the meantime, is there any way I can configure TCPware or GATED as to >what messages to send to OPCOM (or at least to stop sending these >particular messages). Try adding to GATED.CONF the following: options syslog err ; >%%%%%%%%%%% OPCOM 6-APR-1999 10:08:03.03 %%%%%%%%%%% >Message from user SYSTEM on EXTEL >%TCPWARE_GATED-W-WARNING, OSPF RECV 189.1.254.254 -> 224.0.0.5: IP: >bad > destination > >Regards, > >Derek... ================================================================================ Archive-Date: Tue, 6 Apr 1999 10:24:47 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0154B57F@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: GATED OPCOM Warning Messages Date: Tue, 6 Apr 1999 15:26:02 +0100 MIME-Version: 1.0 Content-Type: text/plain Thanks Geoff, Works fine now. Cheers, Derek (who's local supplier support told him it was not possible)... > -----Original Message----- > From: Geoff Bryant [SMTP:bryant@process.com] > Sent: 06 April 1999 14:28 > To: Info-TCPware@process.com > Cc: bryant@process.com > Subject: RE: GATED OPCOM Warning Messages > > Derek Fage writes: > > > >Hi there, > > > >We are in a transitory situation where we have multiple routers > running > >OSPF in defferent logical subnets on the same physical network. (We > hope > >to resolve this in the next month or so as we migrate to VLANs). > > > >In the meantime, is there any way I can configure TCPware or GATED as > to > >what messages to send to OPCOM (or at least to stop sending these > >particular messages). > > Try adding to GATED.CONF the following: > > options syslog err ; > > >%%%%%%%%%%% OPCOM 6-APR-1999 10:08:03.03 %%%%%%%%%%% > >Message from user SYSTEM on EXTEL > >%TCPWARE_GATED-W-WARNING, OSPF RECV 189.1.254.254 -> 224.0.0.5: IP: > >bad > > destination > > > >Regards, > > > >Derek... *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Tue, 6 Apr 1999 12:14:11 -0400 Subject: Re: GATED OPCOM Warning Messages Message-ID: <1999Apr6.090316@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 6 Apr 99 09:03:16 -0500 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F0154B576@RDPEXC01>, Derek Fage writes: > Hi there, > > We are in a transitory situation where we have multiple routers running > OSPF in defferent logical subnets on the same physical network. (We hope > to resolve this in the next month or so as we migrate to VLANs). > > In the meantime, is there any way I can configure TCPware or GATED as to > what messages to send to OPCOM (or at least to stop sending these > particular messages). > > %%%%%%%%%%% OPCOM 6-APR-1999 10:08:03.03 %%%%%%%%%%% > Message from user SYSTEM on EXTEL > %TCPWARE_GATED-W-WARNING, OSPF RECV 189.1.254.254 -> 224.0.0.5: IP: > bad > destination Have you tried playing with the "options syslog" clause in the configuration file? In the 5.3-3 documentation, this is on page 8-10 of the Management Guide. Likely you want to add "options syslog err" (or - Bernie Volz Process Software ================================================================================ Archive-Date: Tue, 6 Apr 1999 19:14:33 -0400 From: chc@cs.cmu.edu (Chang-Hsin Chang) Reply-To: Info-TCPware@process.com Subject: How to get DNS address ?? Date: Tue, 06 Apr 1999 23:06:29 GMT Message-ID: <370c9368.1661058@news.clark.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM After I connect to my ISP, Which API I can I use to get the DNS address ? ================================================================================ Archive-Date: Wed, 7 Apr 1999 09:42:08 -0400 Subject: Re: How to get DNS address ?? Message-ID: <1999Apr7.093132@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 7 Apr 99 09:31:32 -0500 To: Info-TCPware@PROCESS.COM In article <370c9368.1661058@news.clark.net>, chc@cs.cmu.edu (Chang-Hsin Chang) writes: > After I connect to my ISP, Which API I can I use to get the DNS > address ? > I'm not exactly sure what you are looking to obtain. If you know your DNS Name and want the address: - From DCL, use NETCU SHOW HOST - From a program, gethostbyname is typically used If you know your address and want the name: - From DCL, use NETCU SHOW HOST
- From a program, gethostbyaddr is typically used If you want your local host name, you can usually call gethostname. For more details, refer to the Socket Routines (in the C Run-Time documentation or in the TCPware documentation). - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 8 Apr 1999 17:11:11 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017534E1@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: Purveyor 2.0 patches ? Date: Thu, 8 Apr 1999 22:13:32 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, I was just wondering if there were any patches available for Purveyor 2.0 for OpenVMS. The reason that I ask is that we have had a couple of instances when the web server has become unresponsive and needed to be restarted. This is currently running on OpenVMS 7.1-1H2 Alpha Cluster members with UCX 4.2 ECO-1 (soon to be TCPware). Additionally, we have been evaluating TCPware v5.3-2 on our test/dev alphaserver - if we plan to roll TCPware into production would you recommend this, v5.3-3, or any patches ? We plan to upgrade the cluster next weekend, so if we are going to use something other than what is on the development system I'd like to upgrade that this weekend to run it for a week. Regards, Derek... *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 8 Apr 1999 18:20:19 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8601197B99@lespaul.process.com> From: Matt Brightman Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor 2.0 patches ? Date: Thu, 8 Apr 1999 18:20:51 -0400 MIME-Version: 1.0 Content-Type: text/plain Derek, There is a patch for Purveyor that addressed a problem where the server would hang as you described. I'm going to include the instructions for downloading it at the end of this message. Regards, -Matt Brightman ---------------------------------------------------------------- Matthew P. Brightman Email: brightman@process.com Process Software Corporation Phone: 800-722-7770 x371 959 Concord Street Fax: 508-879-0042 Framingham, MA 01701 http://www.process.com ---------------------------------------------------------------- The Purveyor Encrypt WebServer for OpenVMS Version 2.0-1 software kit is available via the Process Software anonymous FTP server on the Internet. To get the kit, you can either use your browser or follow the FTP downloading instructions. This software has export restrictions! None of the Software or underlying information or technology may be downloaded or otherwise exported or reexported (i) into (or to a national or resident of) Cuba, Iraq, Libya, Yugoslavia, North Korea, Iran, Syria or any other country to which the U.S. has embargoed goods; or (ii) to anyone on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Commerce Department's Table of Denial Orders. By installing or using the Software, you are agreeing to the foregoing and you are representing and warranting that you are not located in, under the control of, or a national or resident of any such country or on any such list. Downloading via the World-Wide Web Use the following URLs to download the kit, documentation and UNZIP for VAX and ALPHA - http://vms.process.com/ftp/purveyor/vms/PURVEYOR_EX_V201.ZIP http://vms.process.com/ftp/purveyor/vms/PURVEYOR020-DOC.ZIP http://vms.process.com/ftp/purveyor/vms/UNZIP-VAX.EXE http://vms.process.com/ftp/purveyor/vms/UNZIP-AXP.EXE Downloading via FTP 1.Start FTP and connect to the server (type: ftp ftp.process.com). 2.Login as anonymous (type: anonymous). 3.Use your email address as the password (type: me@mydomain). 4.Use the CD command to get to the Purveyor directory (type: cd purveyor). 5.Use the CD command to get to the VMS directory (type: cd vms). Please note that you will be unable to list the contents of this directory! 6.Set the transfer mode to image (type: type image). 7.Get the Purveyor kit (ZIP file), type: get PURVEYOR_EX_V201.ZIP. 8.Get the Purveyor postscript documentation (ZIP file) if desired, type: get PURVEYOR020-DOC.ZIP. 9.Get the UNZIP program if you don't already have it. For VAX, type: get UNZIP-VAX.EXE. For Alpha, type: get UNZIP-AXP.EXE. 10.Exit from FTP (type: quit). Installing Purveyor Encrypt WebServer for OpenVMS After downloading the Purveyor ZIP file and UNZIP program: 1.Define the UNZIP foreign command: For VAX, type: UNZIP :== $device:[directory]UNZIP-VAX For Alpha, type: UNZIP :== $device:[directory]UNZIP-AXP 2.UNZIP the Purveyor kit, type: UNZIP PURVEYOR_EX_V201.ZIP. 3.UNZIP the Purveyor postscript documentation (if obtained), type: UNZIP PURVEYOR020-DOC.ZIP. There are two files - PURVMSAG.PS (the Administrator's Guide) and PURVMSPG.PS (the Programmer's Guide). If these files don't print properly on your postscript printer, please either use the on-line documentation (see below) or contact Process Software to request hardcopy documentation. 4.Install the Purveyor Encrypt WebServer for OpenVMS product using VMSINSTAL. For complete installation instructions, refer to the Purveyor WebServer for OpenVMS Administrator's Guide (available online at http://vms.process.com/~help/help.html ) You can read the entire Administrator's Guide on-line. ================================================================================ Archive-Date: Thu, 8 Apr 1999 18:49:11 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017534E3@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor 2.0 patches ? Date: Thu, 8 Apr 1999 23:51:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Matt, I'm busy downloading them now. Any comments about TCPware versions / patches ? Cheers, Derek... > -----Original Message----- > From: Matt Brightman [SMTP:Brightman@process.com] > Sent: 08 April 1999 23:21 > To: 'Info-TCPware@process.com' > Subject: RE: Purveyor 2.0 patches ? > > Derek, > > There is a patch for Purveyor that addressed a problem where the > server > would hang as you described. I'm going to include the instructions > for > downloading it at the end of this message. > > Regards, > -Matt Brightman > ---------------------------------------------------------------- > Matthew P. Brightman Email: brightman@process.com > Process Software Corporation Phone: 800-722-7770 x371 > 959 Concord Street Fax: 508-879-0042 > Framingham, MA 01701 http://www.process.com > ---------------------------------------------------------------- > > > > The Purveyor Encrypt WebServer for OpenVMS Version 2.0-1 software kit > is available via the Process Software anonymous FTP server on the > Internet. > > To get the kit, you can either use your browser or follow the FTP > downloading instructions. > > > This software has export restrictions! > > None of the Software or underlying information or technology may be > downloaded or otherwise exported or reexported (i) into (or to a > national or resident of) Cuba, Iraq, Libya, Yugoslavia, North Korea, > Iran, Syria or any other country to which the U.S. has embargoed > goods; > or (ii) to anyone on the U.S. Treasury Department's list of Specially > Designated Nationals or the U.S. Commerce Department's Table of Denial > > Orders. By installing or using the Software, you are agreeing to the > foregoing and you are representing and warranting that you are not > located in, under the control of, or a national or resident of any > such country or on any such list. > > Downloading via the World-Wide Web > > Use the following URLs to download the kit, documentation and UNZIP > for VAX and ALPHA - > > http://vms.process.com/ftp/purveyor/vms/PURVEYOR_EX_V201.ZIP > http://vms.process.com/ftp/purveyor/vms/PURVEYOR020-DOC.ZIP > http://vms.process.com/ftp/purveyor/vms/UNZIP-VAX.EXE > http://vms.process.com/ftp/purveyor/vms/UNZIP-AXP.EXE > > Downloading via FTP > > 1.Start FTP and connect to the server (type: ftp ftp.process.com). > > 2.Login as anonymous (type: anonymous). > > 3.Use your email address as the password (type: me@mydomain). > > 4.Use the CD command to get to the Purveyor directory (type: cd > purveyor). > > 5.Use the CD command to get to the VMS directory (type: cd vms). > Please note that you will be unable to list the contents of this > directory! > > 6.Set the transfer mode to image (type: type image). > > 7.Get the Purveyor kit (ZIP file), type: get PURVEYOR_EX_V201.ZIP. > > 8.Get the Purveyor postscript documentation (ZIP file) if desired, > type: > get > PURVEYOR020-DOC.ZIP. > > 9.Get the UNZIP program if you don't already have it. > For VAX, type: get UNZIP-VAX.EXE. > For Alpha, type: get UNZIP-AXP.EXE. > > 10.Exit from FTP (type: quit). > > Installing Purveyor Encrypt WebServer for OpenVMS > > After downloading the Purveyor ZIP file and UNZIP program: > > 1.Define the UNZIP foreign command: > For VAX, type: UNZIP :== $device:[directory]UNZIP-VAX > For Alpha, type: UNZIP :== $device:[directory]UNZIP-AXP > > 2.UNZIP the Purveyor kit, type: UNZIP PURVEYOR_EX_V201.ZIP. > > 3.UNZIP the Purveyor postscript documentation (if obtained), type: > UNZIP PURVEYOR020-DOC.ZIP. > There are two files - PURVMSAG.PS (the Administrator's Guide) and > > PURVMSPG.PS (the Programmer's Guide). If these files don't print > properly on your postscript printer, please either use the > on-line > documentation (see below) or contact Process Software to request > hardcopy documentation. > > 4.Install the Purveyor Encrypt WebServer for OpenVMS product using > VMSINSTAL. For complete installation instructions, refer to the > Purveyor WebServer for OpenVMS Administrator's Guide (available > online at http://vms.process.com/~help/help.html ) You can > read the entire Administrator's Guide on-line. *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 8 Apr 1999 18:52:53 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017534E4@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor 2.0 patches ? Date: Thu, 8 Apr 1999 23:55:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Matt, Are there any release notes for this patch ? Cheers, Derek... > -----Original Message----- > From: Matt Brightman [SMTP:Brightman@process.com] > Sent: 08 April 1999 23:21 > To: 'Info-TCPware@process.com' > Subject: RE: Purveyor 2.0 patches ? > > Derek, > > There is a patch for Purveyor that addressed a problem where the > server > would hang as you described. I'm going to include the instructions > for > downloading it at the end of this message. > > Regards, > -Matt Brightman > ---------------------------------------------------------------- > Matthew P. Brightman Email: brightman@process.com > Process Software Corporation Phone: 800-722-7770 x371 > 959 Concord Street Fax: 508-879-0042 > Framingham, MA 01701 http://www.process.com > ---------------------------------------------------------------- > > > > The Purveyor Encrypt WebServer for OpenVMS Version 2.0-1 software kit > is available via the Process Software anonymous FTP server on the > Internet. > > To get the kit, you can either use your browser or follow the FTP > downloading instructions. > > > This software has export restrictions! > > None of the Software or underlying information or technology may be > downloaded or otherwise exported or reexported (i) into (or to a > national or resident of) Cuba, Iraq, Libya, Yugoslavia, North Korea, > Iran, Syria or any other country to which the U.S. has embargoed > goods; > or (ii) to anyone on the U.S. Treasury Department's list of Specially > Designated Nationals or the U.S. Commerce Department's Table of Denial > > Orders. By installing or using the Software, you are agreeing to the > foregoing and you are representing and warranting that you are not > located in, under the control of, or a national or resident of any > such country or on any such list. > > Downloading via the World-Wide Web > > Use the following URLs to download the kit, documentation and UNZIP > for VAX and ALPHA - > > http://vms.process.com/ftp/purveyor/vms/PURVEYOR_EX_V201.ZIP > http://vms.process.com/ftp/purveyor/vms/PURVEYOR020-DOC.ZIP > http://vms.process.com/ftp/purveyor/vms/UNZIP-VAX.EXE > http://vms.process.com/ftp/purveyor/vms/UNZIP-AXP.EXE > > Downloading via FTP > > 1.Start FTP and connect to the server (type: ftp ftp.process.com). > > 2.Login as anonymous (type: anonymous). > > 3.Use your email address as the password (type: me@mydomain). > > 4.Use the CD command to get to the Purveyor directory (type: cd > purveyor). > > 5.Use the CD command to get to the VMS directory (type: cd vms). > Please note that you will be unable to list the contents of this > directory! > > 6.Set the transfer mode to image (type: type image). > > 7.Get the Purveyor kit (ZIP file), type: get PURVEYOR_EX_V201.ZIP. > > 8.Get the Purveyor postscript documentation (ZIP file) if desired, > type: > get > PURVEYOR020-DOC.ZIP. > > 9.Get the UNZIP program if you don't already have it. > For VAX, type: get UNZIP-VAX.EXE. > For Alpha, type: get UNZIP-AXP.EXE. > > 10.Exit from FTP (type: quit). > > Installing Purveyor Encrypt WebServer for OpenVMS > > After downloading the Purveyor ZIP file and UNZIP program: > > 1.Define the UNZIP foreign command: > For VAX, type: UNZIP :== $device:[directory]UNZIP-VAX > For Alpha, type: UNZIP :== $device:[directory]UNZIP-AXP > > 2.UNZIP the Purveyor kit, type: UNZIP PURVEYOR_EX_V201.ZIP. > > 3.UNZIP the Purveyor postscript documentation (if obtained), type: > UNZIP PURVEYOR020-DOC.ZIP. > There are two files - PURVMSAG.PS (the Administrator's Guide) and > > PURVMSPG.PS (the Programmer's Guide). If these files don't print > properly on your postscript printer, please either use the > on-line > documentation (see below) or contact Process Software to request > hardcopy documentation. > > 4.Install the Purveyor Encrypt WebServer for OpenVMS product using > VMSINSTAL. For complete installation instructions, refer to the > Purveyor WebServer for OpenVMS Administrator's Guide (available > online at http://vms.process.com/~help/help.html ) You can > read the entire Administrator's Guide on-line. *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 8 Apr 1999 18:55:06 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8601197B9B@lespaul.process.com> From: Matt Brightman Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor 2.0 patches ? Date: Thu, 8 Apr 1999 18:55:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I would recommend TCPware v5.3-3 with the latest NETCP and DRIVERS patches. Regards, -Matt Brightman ---------------------------------------------------------------- Matthew P. Brightman Email: brightman@process.com Process Software Corporation Phone: 800-722-7770 x371 959 Concord Street Fax: 508-879-0042 Framingham, MA 01701 http://www.process.com ---------------------------------------------------------------- > -----Original Message----- > From: Derek Fage [mailto:Derekf@ITEXJSY.com] > Sent: Thursday, April 08, 1999 6:51 PM > To: 'Info-TCPware@process.com' > Subject: RE: Purveyor 2.0 patches ? > > > Thanks Matt, > > I'm busy downloading them now. > > Any comments about TCPware versions / patches ? > > Cheers, > > Derek... > > > -----Original Message----- > > From: Matt Brightman [SMTP:Brightman@process.com] > > Sent: 08 April 1999 23:21 > > To: 'Info-TCPware@process.com' > > Subject: RE: Purveyor 2.0 patches ? > > > > Derek, > > > > There is a patch for Purveyor that addressed a problem where the > > server > > would hang as you described. I'm going to include the instructions > > for > > downloading it at the end of this message. > > > > Regards, > > -Matt Brightman > > ---------------------------------------------------------------- > > Matthew P. Brightman Email: brightman@process.com > > Process Software Corporation Phone: 800-722-7770 x371 > > 959 Concord Street Fax: 508-879-0042 > > Framingham, MA 01701 http://www.process.com > > ---------------------------------------------------------------- > > > > > > > > The Purveyor Encrypt WebServer for OpenVMS Version 2.0-1 > software kit > > is available via the Process Software anonymous FTP server on the > > Internet. > > > > To get the kit, you can either use your browser or follow the FTP > > downloading instructions. > > > > > > This software has export restrictions! > > > > None of the Software or underlying information or technology may be > > downloaded or otherwise exported or reexported (i) into (or to a > > national or resident of) Cuba, Iraq, Libya, Yugoslavia, > North Korea, > > Iran, Syria or any other country to which the U.S. has embargoed > > goods; > > or (ii) to anyone on the U.S. Treasury Department's list of > Specially > > Designated Nationals or the U.S. Commerce Department's > Table of Denial > > > > Orders. By installing or using the Software, you are agreeing to the > > foregoing and you are representing and warranting that you are not > > located in, under the control of, or a national or resident of any > > such country or on any such list. > > > > Downloading via the World-Wide Web > > > > Use the following URLs to download the kit, documentation and UNZIP > > for VAX and ALPHA - > > > > http://vms.process.com/ftp/purveyor/vms/PURVEYOR_EX_V201.ZIP > > http://vms.process.com/ftp/purveyor/vms/PURVEYOR020-DOC.ZIP > > http://vms.process.com/ftp/purveyor/vms/UNZIP-VAX.EXE > > http://vms.process.com/ftp/purveyor/vms/UNZIP-AXP.EXE > > > > Downloading via FTP > > > > 1.Start FTP and connect to the server (type: ftp > ftp.process.com). > > > > 2.Login as anonymous (type: anonymous). > > > > 3.Use your email address as the password (type: me@mydomain). > > > > 4.Use the CD command to get to the Purveyor directory (type: cd > > purveyor). > > > > 5.Use the CD command to get to the VMS directory (type: cd vms). > > Please note that you will be unable to list the > contents of this > > directory! > > > > 6.Set the transfer mode to image (type: type image). > > > > 7.Get the Purveyor kit (ZIP file), type: get > PURVEYOR_EX_V201.ZIP. > > > > 8.Get the Purveyor postscript documentation (ZIP file) > if desired, > > type: > > get > > PURVEYOR020-DOC.ZIP. > > > > 9.Get the UNZIP program if you don't already have it. > > For VAX, type: get UNZIP-VAX.EXE. > > For Alpha, type: get UNZIP-AXP.EXE. > > > > 10.Exit from FTP (type: quit). > > > > Installing Purveyor Encrypt WebServer for OpenVMS > > > > After downloading the Purveyor ZIP file and UNZIP program: > > > > 1.Define the UNZIP foreign command: > > For VAX, type: UNZIP :== $device:[directory]UNZIP-VAX > > For Alpha, type: UNZIP :== $device:[directory]UNZIP-AXP > > > > 2.UNZIP the Purveyor kit, type: UNZIP PURVEYOR_EX_V201.ZIP. > > > > 3.UNZIP the Purveyor postscript documentation (if > obtained), type: > > UNZIP PURVEYOR020-DOC.ZIP. > > There are two files - PURVMSAG.PS (the Administrator's > Guide) and > > > > PURVMSPG.PS (the Programmer's Guide). If these files > don't print > > properly on your postscript printer, please either use the > > on-line > > documentation (see below) or contact Process Software > to request > > hardcopy documentation. > > > > 4.Install the Purveyor Encrypt WebServer for OpenVMS > product using > > VMSINSTAL. For complete installation instructions, > refer to the > > Purveyor WebServer for OpenVMS Administrator's Guide (available > > online at http://vms.process.com/~help/help.html ) You can > > read the entire Administrator's Guide on-line. > ************************************************************** > ********* > 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 > 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 to administrator@itexjsy.com. > ************************************************************** > ********* > ================================================================================ Archive-Date: Thu, 8 Apr 1999 19:07:24 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017534E5@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor 2.0 patches ? Date: Fri, 9 Apr 1999 00:09:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Matt, Can I obtain these kits from your FTP server ? Derek... > -----Original Message----- > From: Matt Brightman [SMTP:Brightman@process.com] > Sent: 08 April 1999 23:56 > To: 'Info-TCPware@process.com' > Subject: RE: Purveyor 2.0 patches ? > > I would recommend TCPware v5.3-3 with the latest NETCP and DRIVERS > patches. > > Regards, > -Matt Brightman > ---------------------------------------------------------------- > Matthew P. Brightman Email: brightman@process.com > Process Software Corporation Phone: 800-722-7770 x371 > 959 Concord Street Fax: 508-879-0042 > Framingham, MA 01701 http://www.process.com > ---------------------------------------------------------------- > > > > -----Original Message----- > > From: Derek Fage [mailto:Derekf@ITEXJSY.com] > > Sent: Thursday, April 08, 1999 6:51 PM > > To: 'Info-TCPware@process.com' > > Subject: RE: Purveyor 2.0 patches ? > > > > > > Thanks Matt, > > > > I'm busy downloading them now. > > > > Any comments about TCPware versions / patches ? > > > > Cheers, > > > > Derek... > > > > > -----Original Message----- > > > From: Matt Brightman [SMTP:Brightman@process.com] > > > Sent: 08 April 1999 23:21 > > > To: 'Info-TCPware@process.com' > > > Subject: RE: Purveyor 2.0 patches ? > > > > > > Derek, > > > > > > There is a patch for Purveyor that addressed a problem where the > > > server > > > would hang as you described. I'm going to include the > instructions > > > for > > > downloading it at the end of this message. > > > > > > Regards, > > > -Matt Brightman > > > ---------------------------------------------------------------- > > > Matthew P. Brightman Email: brightman@process.com > > > Process Software Corporation Phone: 800-722-7770 x371 > > > 959 Concord Street Fax: 508-879-0042 > > > Framingham, MA 01701 http://www.process.com > > > ---------------------------------------------------------------- > > > > > > > > > > > > The Purveyor Encrypt WebServer for OpenVMS Version 2.0-1 > > software kit > > > is available via the Process Software anonymous FTP server on the > > > Internet. > > > > > > To get the kit, you can either use your browser or follow the FTP > > > downloading instructions. > > > > > > > > > This software has export restrictions! > > > > > > None of the Software or underlying information or technology may > be > > > downloaded or otherwise exported or reexported (i) into (or to a > > > national or resident of) Cuba, Iraq, Libya, Yugoslavia, > > North Korea, > > > Iran, Syria or any other country to which the U.S. has embargoed > > > goods; > > > or (ii) to anyone on the U.S. Treasury Department's list of > > Specially > > > Designated Nationals or the U.S. Commerce Department's > > Table of Denial > > > > > > Orders. By installing or using the Software, you are agreeing to > the > > > foregoing and you are representing and warranting that you are not > > > > located in, under the control of, or a national or resident of any > > > > such country or on any such list. > > > > > > Downloading via the World-Wide Web > > > > > > Use the following URLs to download the kit, documentation and > UNZIP > > > for VAX and ALPHA - > > > > > > http://vms.process.com/ftp/purveyor/vms/PURVEYOR_EX_V201.ZIP > > > http://vms.process.com/ftp/purveyor/vms/PURVEYOR020-DOC.ZIP > > > http://vms.process.com/ftp/purveyor/vms/UNZIP-VAX.EXE > > > http://vms.process.com/ftp/purveyor/vms/UNZIP-AXP.EXE > > > > > > Downloading via FTP > > > > > > 1.Start FTP and connect to the server (type: ftp > > ftp.process.com). > > > > > > 2.Login as anonymous (type: anonymous). > > > > > > 3.Use your email address as the password (type: me@mydomain). > > > > > > 4.Use the CD command to get to the Purveyor directory (type: cd > > > purveyor). > > > > > > 5.Use the CD command to get to the VMS directory (type: cd > vms). > > > Please note that you will be unable to list the > > contents of this > > > directory! > > > > > > 6.Set the transfer mode to image (type: type image). > > > > > > 7.Get the Purveyor kit (ZIP file), type: get > > PURVEYOR_EX_V201.ZIP. > > > > > > 8.Get the Purveyor postscript documentation (ZIP file) > > if desired, > > > type: > > > get > > > PURVEYOR020-DOC.ZIP. > > > > > > 9.Get the UNZIP program if you don't already have it. > > > For VAX, type: get UNZIP-VAX.EXE. > > > For Alpha, type: get UNZIP-AXP.EXE. > > > > > > 10.Exit from FTP (type: quit). > > > > > > Installing Purveyor Encrypt WebServer for OpenVMS > > > > > > After downloading the Purveyor ZIP file and UNZIP program: > > > > > > 1.Define the UNZIP foreign command: > > > For VAX, type: UNZIP :== $device:[directory]UNZIP-VAX > > > For Alpha, type: UNZIP :== $device:[directory]UNZIP-AXP > > > > > > 2.UNZIP the Purveyor kit, type: UNZIP PURVEYOR_EX_V201.ZIP. > > > > > > 3.UNZIP the Purveyor postscript documentation (if > > obtained), type: > > > UNZIP PURVEYOR020-DOC.ZIP. > > > There are two files - PURVMSAG.PS (the Administrator's > > Guide) and > > > > > > PURVMSPG.PS (the Programmer's Guide). If these files > > don't print > > > properly on your postscript printer, please either use the > > > on-line > > > documentation (see below) or contact Process Software > > to request > > > hardcopy documentation. > > > > > > 4.Install the Purveyor Encrypt WebServer for OpenVMS > > product using > > > VMSINSTAL. For complete installation instructions, > > refer to the > > > Purveyor WebServer for OpenVMS Administrator's Guide > (available > > > online at http://vms.process.com/~help/help.html ) You can > > > read the entire Administrator's Guide on-line. > > ************************************************************** > > ********* > > 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 > > 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 to administrator@itexjsy.com. > > ************************************************************** > > ********* > > *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 9 Apr 1999 07:55:16 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Size of NETCP.LOG files Date: Fri, 9 Apr 1999 12:30:01 +0100 Message-ID: <7ekobj$4tv$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM Config: Clustered VAX 65xx, VAX 7820s, OpenVMS V5.5-2 and V6.2, TCPware V5.3-2... The size of the NETCP.LOG files on some of our production systems now exceeds 200,000 blocks (they were created on 27-Mar-1999). Past experience has shown that TCPware has a whole stack of (to me) undocumented logical names to control various aspects of it's behaviour. Is there anything that would help control/filter the information recorded in the file ? I really don't want to push the whole thing to the null device because it could be valuable... Thanks for any help ! Best regards, -Andy ================================================================================ Archive-Date: Fri, 9 Apr 1999 08:03:15 -0400 Sender: bryant@process.com Date: Fri, 9 Apr 1999 08:03:49 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D65E7.F6DB83FA.39@process.com> Subject: RE: Size of NETCP.LOG files "Andy Williams" writes: > >Config: Clustered VAX 65xx, VAX 7820s, OpenVMS V5.5-2 and V6.2, TCPware >V5.3-2... > >The size of the NETCP.LOG files on some of our production systems now >exceeds 200,000 blocks (they were created on 27-Mar-1999). Past experience >has shown that TCPware has a whole stack of (to me) undocumented logical >names to control various aspects of it's behaviour. Is there anything that >would help control/filter the information recorded in the file ? I really >don't want to push the whole thing to the null device because it could be >valuable... > >Thanks for any help ! > >Best regards, > >-Andy Aside from any logicals, you might want to use the NETCU SET LOG/NEW file command to close out the current log file and start up a new one. That should allow you to do some cleanup. ------------------------------------------------------------- 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, 9 Apr 1999 08:11:39 -0400 Subject: RE: Purveyor 2.0 patches ? Message-ID: <1999Apr9.080303@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 9 Apr 99 08:03:03 -0500 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F017534E5@RDPEXC01>, Derek Fage writes: > Matt, > > Can I obtain these kits from your FTP server ? > > Derek... Yes, you can. FTP to FTP.TCPWARE.PROCESS.COM and cd to the support directory. CD to the 53_3 directory. There is a 00SUMMARY.TXT file that provides a summary of the patches available. - Bernie Volz Process Software ================================================================================ Archive-Date: Fri, 9 Apr 1999 08:20:19 -0400 Sender: schreiber@process.com Date: Fri, 9 Apr 1999 08:20:51 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D65EA.57D5D4A1.5@process.com> Subject: RE: Size of NETCP.LOG files Geoff Bryant writes: > >"Andy Williams" writes: >> >>The size of the NETCP.LOG files on some of our production systems now >>exceeds 200,000 blocks (they were created on 27-Mar-1999). >> > >Aside from any logicals, you might want to use the > > NETCU SET LOG/NEW file > >command to close out the current log file and start up a new one. That >should allow you to do some cleanup. > It may also be beneficial to take a look at what all is going on in there... 200,000 blocks is a bit excessive for 2 weeks... there may be a problem that is resulting in lots of logging. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 9 Apr 1999 08:30:53 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017534FC@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor 2.0 patches ? Date: Fri, 9 Apr 1999 13:33:19 +0100 MIME-Version: 1.0 Content-Type: text/plain Bernie, The patches for 5.3-3 appear to be here, but is there a kit I need to upgrade from 5.3-2 to 5.3-3 ? Cheers, Derek... > -----Original Message----- > From: volz@process.com [SMTP:volz@process.com] > Sent: 09 April 1999 14:03 > To: Info-TCPware@PROCESS.COM > Subject: RE: Purveyor 2.0 patches ? > > In article <49B21CD935D0D011B4980000F875254F017534E5@RDPEXC01>, Derek > Fage writes: > > Matt, > > > > Can I obtain these kits from your FTP server ? > > > > Derek... > > Yes, you can. FTP to FTP.TCPWARE.PROCESS.COM and cd to the support > directory. > CD to the 53_3 directory. There is a 00SUMMARY.TXT file that provides > a > summary of the patches available. > > - Bernie Volz > Process Software *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 9 Apr 1999 08:45:14 -0400 Subject: Re: Size of NETCP.LOG files Message-ID: <1999Apr9.080917@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 9 Apr 99 08:09:17 -0500 To: Info-TCPware@PROCESS.COM In article <7ekobj$4tv$1@gatekeeper.liffe.com>, "Andy Williams" writes: > Config: Clustered VAX 65xx, VAX 7820s, OpenVMS V5.5-2 and V6.2, TCPware > V5.3-2... > > The size of the NETCP.LOG files on some of our production systems now > exceeds 200,000 blocks (they were created on 27-Mar-1999). Past experience > has shown that TCPware has a whole stack of (to me) undocumented logical > names to control various aspects of it's behaviour. Is there anything that > would help control/filter the information recorded in the file ? I really > don't want to push the whole thing to the null device because it could be > valuable... > > Thanks for any help ! > > Best regards, > > -Andy One option is to use the NETCU SET LOG command to open a new log file. At least then you can move the old log file to another drive if you want to save it (or delete it after a system backup). You might even want to set up a batch job that does this periodically (once a week or whatever frequency you want). - Bernie Volz Process Software ================================================================================ Archive-Date: Fri, 9 Apr 1999 11:12:10 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753503@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: Cluster as Primary DNS Server Date: Fri, 9 Apr 1999 16:14:24 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, I want to make my Primary DNS Server as resilient as possible, so I was wondering whether it was possible to configure all OpenVMS cluster members as DNS Servers (either all primary or one primary and a number of secondary), and then use the cluster alias failover address as the primary DNS address for clients. Regards, Derek... *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 9 Apr 1999 11:28:58 -0400 Sender: schreiber@process.com Date: Fri, 9 Apr 1999 11:29:31 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D6604.B349FBDB.126@process.com> Subject: RE: Cluster as Primary DNS Server Derek Fage writes: > >I want to make my Primary DNS Server as resilient as possible, so I was >wondering whether it was possible to configure all OpenVMS cluster >members as DNS Servers (either all primary or one primary and a number >of secondary), and then use the cluster alias failover address as the >primary DNS address for clients. > No... First off, using the cluster alias failover address isn't going to work the way you would think. Since the protocol is UDP based, when the system sends responses, it doesn't know the context that it's a reply, and a moreso what address the UDP datagram was sent to that this datagram is a reply to. So it puts the IP address in the reply... the primary IP address, rather than the cluster failover address. A lot of resolvers verify that the answer came from the address it was sent to... and they won't accept the answer. There are also a lot of other issues as far as timing goes if it actually does fail over. However, DNS in general is defined to provide failover an resilience. It's perfectly fine to have the systems configured to be Primary and secondaries...but treat them as multiple systems. Configure your resolvers to point to each individual server. Another, even broader approach is one that can be gleamed from the Multinet default configuration. Where each system defaults to be a caching server. The resolvers all point to 127.0.0.1, then you can have the caching servers configured to forward to each system in the cluster. Once the NS records for the zone that your cluster systems are all authoritative for is in the caching servers cache, it uses some complex ordering techniques to decide what order to query the authoritative nameservers for the zone... based on response time and number of queries sent to each server. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 9 Apr 1999 11:39:52 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753504@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Cluster as Primary DNS Server Date: Fri, 9 Apr 1999 16:42:07 +0100 MIME-Version: 1.0 Content-Type: text/plain Thanks Jeff, VMS resolvers are OK - The problem is that PC clients tend to have timeout problems resolving names when the primary is down and it needs to use the secondary. Cheers, Derek... > -----Original Message----- > From: Jeff Schreiber [SMTP:schreiber@process.com] > Sent: 09 April 1999 16:30 > To: Info-TCPware@process.com > Cc: schreiber@process.com > Subject: RE: Cluster as Primary DNS Server > > Derek Fage writes: > > > >I want to make my Primary DNS Server as resilient as possible, so I > was > >wondering whether it was possible to configure all OpenVMS cluster > >members as DNS Servers (either all primary or one primary and a > number > >of secondary), and then use the cluster alias failover address as the > >primary DNS address for clients. > > > > No... First off, using the cluster alias failover address isn't > going > to work the way you would think. Since the protocol is UDP based, > > when the system sends responses, it doesn't know the context that > it's > a reply, and a moreso what address the UDP datagram was sent to > that > this datagram is a reply to. > > So it puts the IP address in the reply... the primary IP address, > rather > than the cluster failover address. A lot of resolvers verify that > the > answer came from the address it was sent to... and they won't > accept the > answer. > > There are also a lot of other issues as far as timing goes if it > actually > does fail over. > > However, DNS in general is defined to provide failover an > resilience. It's > perfectly fine to have the systems configured to be Primary and > secondaries...but treat them as multiple systems. Configure your > resolvers > to point to each individual server. > > Another, even broader approach is one that can be gleamed from the > Multinet > default configuration. Where each system defaults to be a caching > > server. The resolvers all point to 127.0.0.1, then you can have > the > caching servers configured to forward to each system in the > cluster. Once > the NS records for the zone that your cluster systems are all > authoritative > for is in the caching servers cache, it uses some complex ordering > > techniques to decide what order to query the authoritative > nameservers > for the zone... based on response time and number of queries sent > to > each server. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 9 Apr 1999 17:41:40 -0400 Subject: RE: Purveyor 2.0 patches ? Message-ID: <1999Apr9.171504@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 9 Apr 99 17:15:04 -0500 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F017534FC@RDPEXC01>, Derek Fage writes: > Bernie, > > The patches for 5.3-3 appear to be here, but is there a kit I need to > upgrade from 5.3-2 to 5.3-3 ? > > Cheers, > > Derek... Please contact our technical support folks regarding this issue. I'll forward it on to make sure that they see it. - Bernie Volz Process Software ================================================================================ Archive-Date: Fri, 9 Apr 1999 17:41:44 -0400 Subject: RE: Cluster as Primary DNS Server Message-ID: <1999Apr9.171402@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 9 Apr 99 17:14:02 -0500 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F01753504@RDPEXC01>, Derek Fage writes: > Thanks Jeff, > > VMS resolvers are OK - The problem is that PC clients tend to have > timeout problems resolving names when the primary is down and it needs > to use the secondary. > > Cheers, > > Derek... You should not just give the PC's one DNS server address. Most DNS resolver software will support more than one. So, give your PCs the address of more than one server. That way, when the first listed is down, it will try the second. This will result in a small resolving delay. TCPware's resolver supports 3 addresses. - Bernie Volz Process Software ================================================================================ Archive-Date: Sat, 10 Apr 1999 06:33:12 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753505@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor 2.0 patches ? Date: Fri, 9 Apr 1999 17:56:06 +0100 MIME-Version: 1.0 Content-Type: text/plain Bernie, I've got the 5.3-3 kit from my supplier. Thanks for your help, Derek... > -----Original Message----- > From: Derek Fage [SMTP:Derekf@ITEXJSY.com] > Sent: 09 April 1999 13:33 > To: 'Info-TCPware@process.com' > Subject: RE: Purveyor 2.0 patches ? > > Bernie, > > The patches for 5.3-3 appear to be here, but is there a kit I need to > upgrade from 5.3-2 to 5.3-3 ? > > Cheers, > > Derek... > > > -----Original Message----- > > From: volz@process.com [SMTP:volz@process.com] > > Sent: 09 April 1999 14:03 > > To: Info-TCPware@PROCESS.COM > > Subject: RE: Purveyor 2.0 patches ? > > > > In article <49B21CD935D0D011B4980000F875254F017534E5@RDPEXC01>, > Derek > > Fage writes: > > > Matt, > > > > > > Can I obtain these kits from your FTP server ? > > > > > > Derek... > > > > Yes, you can. FTP to FTP.TCPWARE.PROCESS.COM and cd to the support > > directory. > > CD to the 53_3 directory. There is a 00SUMMARY.TXT file that > provides > > a > > summary of the patches available. > > > > - Bernie Volz > > Process Software > ********************************************************************** > * > 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 > 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 to administrator@itexjsy.com. > ********************************************************************** > * *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Sat, 10 Apr 1999 22:05:44 -0400 From: "Brian Steele" Reply-To: Info-TCPware@process.com Subject: DEC Printserver 20, LPS print queues Date: Sat, 10 Apr 1999 15:57:40 -0400 Message-ID: <7eoagv$26f1@col3.caribsurf.com> To: Info-TCPware@PROCESS.COM Hi Everyone: Sorry about the cross-post, but I wasn't sure which to which newsgroup this should be addressed... I've got two Digital Printserver 20s on our LAN, and my VAX has several generic queues and two device queues on it that point to these printservers. The protocol used for the queues is DECnet, and the device queues are configured as follows: /DEFAULT=(FLAG,FORM=LAS5_P_0 (stock=DEFAULT)) /NOENABLE_GENERIC /LIBRARY=DCPS_LIB Lowercase /OWNER=[SYSTEM] /PROCESSOR=DCPS$SMB /PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE) /SEPARATE=(RESET=(LPS$$EOJ)) I'm using TCPWare 5.3 on the VAX to provide IP services, and for a number of reasons, I'd like to replace the printserver queues mentioned above with equivalent LPS generic queues, the target being device queues offered by an NT server. I've done this quite successfully with print queues pointing to other printers (mostly HP LaserJets), but I can't seem to get the queues for the printservers working properly. TCPWare's LPS config utility creates the queue successfully, but when I submit a print job to the queue, here's what happens: 1. The job enters the queue on the VAX 2. The job then enters the device queue on the NT server 3. The device queue on the NT server reports that the job is printing 4. The job disappears from the device queue on the NT server 5. The job is NOT printed. If I send a print job from the NT server, it prints out Ok on the printserver, so I know that the device queue is set up correctly, Ditto if I connect to the NT's queue from a Win95 PC and try a print job from there. So it must be that something's not right with the queue on the VAX - possibly a formatting problem (which would explain why the printserver doesn't print it). Here's how the generic LPS queue is configured on the VAX - can anyone tell me what's wrong with it? Or, is there something else that I should be looking at? /DEFAULT=(FEED,FLAG,FORM=LAS5_P_0 (stock=DEFAULT)) /LIBRARY=LPS$DEVCTL /OWNER=[SYSTEM] /PROCESSOR=TCPWARE_VMSLPRSMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR /SEPARATE=(RESET=(LPS$$EOJ)) Regards, Brian Steele ================================================================================ Archive-Date: Sun, 11 Apr 1999 11:17:25 -0400 Subject: Re: DEC Printserver 20, LPS print queues Message-ID: <1999Apr11.092626@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 11 Apr 99 09:26:26 -0500 To: Info-TCPware@PROCESS.COM In article <7eoagv$26f1@col3.caribsurf.com>, "Brian Steele" writes: > Hi Everyone: > > Sorry about the cross-post, but I wasn't sure which to which newsgroup this > should be addressed... > > I've got two Digital Printserver 20s on our LAN, and my VAX has several > generic queues and two device queues on it that point to these printservers. > The protocol used for the queues is DECnet, and the device queues are > configured as follows: > > /DEFAULT=(FLAG,FORM=LAS5_P_0 (stock=DEFAULT)) > /NOENABLE_GENERIC > /LIBRARY=DCPS_LIB Lowercase > /OWNER=[SYSTEM] > /PROCESSOR=DCPS$SMB > /PROTECTION=(S:M,O:D,G:R,W:S) > /SCHEDULE=(NOSIZE) > /SEPARATE=(RESET=(LPS$$EOJ)) > > > I'm using TCPWare 5.3 on the VAX to provide IP services, and for a number of > reasons, I'd like to replace the printserver queues mentioned above with > equivalent LPS generic queues, the target being device queues offered by an > NT server. I've done this quite successfully with print queues pointing to > other printers (mostly HP LaserJets), but I can't seem to get the queues for > the printservers working properly. TCPWare's LPS config utility creates the > queue successfully, but when I submit a print job to the queue, here's what > happens: > > 1. The job enters the queue on the VAX > 2. The job then enters the device queue on the NT server > 3. The device queue on the NT server reports that the job is printing > 4. The job disappears from the device queue on the NT server > 5. The job is NOT printed. > > If I send a print job from the NT server, it prints out Ok on the > printserver, so I know that the device queue is set up correctly, Ditto if > I connect to the NT's queue from a Win95 PC and try a print job from there. > So it must be that something's not right with the queue on the VAX - > possibly a formatting problem (which would explain why the printserver > doesn't print it). > > Here's how the generic LPS queue is configured on the VAX - can anyone tell > me what's wrong with it? Or, is there something else that I should be > looking at? > > /DEFAULT=(FEED,FLAG,FORM=LAS5_P_0 (stock=DEFAULT)) > /LIBRARY=LPS$DEVCTL > /OWNER=[SYSTEM] > /PROCESSOR=TCPWARE_VMSLPRSMB > /PROTECTION=(S:M,O:D,G:R,W:S) > /RETAIN=ERROR > /SEPARATE=(RESET=(LPS$$EOJ)) > > > Regards, > Brian Steele The output of TCPWARE_VMSLPRSMB is ASCII text (formatted as VMS would normally do for output to a printer). Depending on what the printer is on the NT server and what that printing system expects, perhaps that's the problem (it wants postscript)? Perhaps you need to check the configuration on the NT Server? If the printer you are printing to is network reachable directly (ie, not connected via a serial or parallel port on the NT system), why not send it the data directly. You might consider configuring DCPS on the VMS system to send the data to a particular TCP/IP address and port number (see the TCPware documentation for details on this). - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 12 Apr 1999 08:08:41 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753523@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: Purveyor CGI errors Date: Mon, 12 Apr 1999 13:10:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, One of our programmers released some changes to his CGI code, and we got some errors reported via OPCOM. He has backed out the changes, but is asking for information on what the problem is likely to be. Can anybody give me some information as to what could be causing these two OPCOM messages: %%%%%%%%%%% OPCOM 12-APR-1999 10:21:02.94 %%%%%%%%%%% Message from user SYSTEM on JERS0A %PURVEYOR-I-WORKERERROR, Worker Purveyor 0005 (202F837C) reported error -PURVEYOR-E-MSGCGIERROR, error in CGI script (invalid or no response header?) -PURVEYOR-I-HTTPREQUEST, last HTTP request was GET / HTTP/1.0 -PURVEYOR-I-WORKERCONN, while processing connection from 130.32.136.244,1133 %%%%%%%%%%% OPCOM 12-APR-1999 10:21:08.94 %%%%%%%%%%% Message from user SYSTEM on JERS0A %PURVEYOR-I-WORKERERROR, Worker Purveyor 0004 (202C317B) reported error -PURVEYOR-E-MSGCGIERROR, error in CGI script (too much response header data?) -PURVEYOR-I-HTTPREQUEST, last HTTP request was GET /ftsbin/w_client?PLANG=ENGLIS H&PUSERP=P_CORE&PPAGE=PT_K&CTYPE=SEDOL&CCODE=5500118 HTTP/1.0 -PURVEYOR-I-WORKERCONN, while processing connection from 194.202.150.135,1107 Cheers, Derek... *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Mon, 12 Apr 1999 11:10:52 -0400 Subject: Re: Purveyor CGI errors Message-ID: <1999Apr12.103242@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 12 Apr 99 10:32:42 -0500 To: Info-TCPware@PROCESS.COM This simple means the response isn't formatted properly. The response *MUST* include the HTTP header followed by a blank line followed by the data. Purveyor will issue the OPCOM messages if the response from the CGI script does not have a valid header within a certain amount of data. In particular, it sounds like the first is caused by a short response which has no blank line and recognizeable error. The 2nd is caused by a LONG response with again no blank line and recognizeable header. For example: ------------------------------------------------------------------------ Content-type: text/html PSC Research & Development ------------------------------------------------------------------------ - Bernie Volz In article <49B21CD935D0D011B4980000F875254F01753523@RDPEXC01>, Derek Fage writes: > Hi there, > > One of our programmers released some changes to his CGI code, and we got > some errors reported via OPCOM. > > He has backed out the changes, but is asking for information on what the > problem is likely to be. > > Can anybody give me some information as to what could be causing these > two OPCOM messages: > > %%%%%%%%%%% OPCOM 12-APR-1999 10:21:02.94 %%%%%%%%%%% > Message from user SYSTEM on JERS0A > %PURVEYOR-I-WORKERERROR, Worker Purveyor 0005 (202F837C) reported > error > -PURVEYOR-E-MSGCGIERROR, error in CGI script (invalid or no response > header?) > -PURVEYOR-I-HTTPREQUEST, last HTTP request was GET / HTTP/1.0 > -PURVEYOR-I-WORKERCONN, while processing connection from > 130.32.136.244,1133 > > %%%%%%%%%%% OPCOM 12-APR-1999 10:21:08.94 %%%%%%%%%%% > Message from user SYSTEM on JERS0A > %PURVEYOR-I-WORKERERROR, Worker Purveyor 0004 (202C317B) reported > error > -PURVEYOR-E-MSGCGIERROR, error in CGI script (too much response header > data?) > -PURVEYOR-I-HTTPREQUEST, last HTTP request was GET > /ftsbin/w_client?PLANG=ENGLIS > H&PUSERP=P_CORE&PPAGE=PT_K&CTYPE=SEDOL&CCODE=5500118 HTTP/1.0 > -PURVEYOR-I-WORKERCONN, while processing connection from > 194.202.150.135,1107 > > Cheers, > > Derek... > *********************************************************************** > Any views expressed in this message are those of the individual sender, > except where the sender states them to be the views of Itex Limited. > > This 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 to administrator@itexjsy.com. > *********************************************************************** ================================================================================ Archive-Date: Tue, 13 Apr 1999 08:24:49 -0400 Subject: Re: How to get DNS address ?? From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <370fd6f3.0@nevada.kapsch.co.at> Date: 11 Apr 1999 00:55:47 +0100 To: Info-TCPware@PROCESS.COM In article <370c9368.1661058@news.clark.net>, chc@cs.cmu.edu (Chang-Hsin Chang) writes: >After I connect to my ISP, Which API I can I use to get the DNS >address ? What do you want ? The IP address the ISP assigned to you via DHCP ? Do you run an DHCP client on your system ? TCPware still does not include one. So no API... The IP adress of DNS servers of your ISP can be found by asking a root name server (IP adresses of them are in the NAMED.CA file). PCs normally get this infos (and more) via the DHCP server. But VMS... Sigh. ------------------------------------------------------------------------ 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, 13 Apr 1999 08:24:53 -0400 Subject: Re: Cluster as Primary DNS Server From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <370fd9e2.0@nevada.kapsch.co.at> Date: 11 Apr 1999 01:08:18 +0100 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F01753503@RDPEXC01>, Derek Fage writes: >I want to make my Primary DNS Server as resilient as possible, so I was >wondering whether it was possible to configure all OpenVMS cluster >members as DNS Servers (either all primary or one primary and a number >of secondary), and then use the cluster alias failover address as the >primary DNS address for clients. Is possible, but might be not the best solution (see Jeff's response) If only PCs (NT4, W95, W98) are DNS clients, there should be no problem. But CISCO Routers, SOLARIS or IRIS PCNFSD and much more have the problems Jeff described... Try it. We decided against, but we run the primary DNS and some secondary DNS servers on VMS, so downtime of the DNS server is usually not the case ;-) PS: Don't confuse "Primary DNS server" with the "first listed DNS server" in the DNS client configuration. They are usually not the same on multi site networks... ------------------------------------------------------------------------ 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, 13 Apr 1999 11:13:24 -0400 Message-ID: <3713552B.34C773A6@SMTP.DeltaTel.RU> Date: Tue, 13 Apr 1999 18:31:07 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: Cluster as Primary DNS Server Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Derek Fage wrote: > > Hi there, > > I want to make my Primary DNS Server as resilient as possible, so I was > wondering whether it was possible to configure all OpenVMS cluster > members as DNS Servers (either all primary or one primary and a number > of secondary), and then use the cluster alias failover address as the > primary DNS address for clients. If you have 5.3-3 you can/must use pseudo-devices, it's more preferable way to use with DNS (take a look to TCPWare 5.3-3 release notes:). You can't use alias addreses (secondary interface address) as IP address of "clustered DNS" server doing of UDP nature. I have several Alphas in a VMS cluster which configured as primary DNS servers, with common system disk where placed TCPware's directories, it's very useful for managing because I have common only one instances of named.boot,*.hosts,*.rev files. > > Regards, > > Derek... > -- 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: Tue, 13 Apr 1999 14:51:53 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753547@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: TCPware REXEC Server Issues Date: Tue, 13 Apr 1999 19:53:54 +0100 MIME-Version: 1.0 Content-Type: text/plain Any news on the availability of this fix ? > -----Original Message----- > From: Hunter Goatley [SMTP:goathunter@PROCESS.COM] > Sent: 29 March 1999 14:18 > To: Info-TCPware@process.com > 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/ *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Sun, 18 Apr 1999 06:50:05 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753589@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: Cluster Alias Failover Problem Date: Sun, 18 Apr 1999 11:42:04 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, I've been running some load tests on our cluster (OpenVMS 7.1-1H2 TCPware 5.3-3) and have come up with a strange error. I am trying to get the cluster alias failover address to go onto a different machine. Normally to do this I would do a NETCU REM SECOND nnn.nnn.nnn.nnn /ABORT on the node that has the active secondary address, and the other node that was queueing for the lock would take it. In this case it did not take over the lock, it just stayed queued. I added the secondary address to the 'primary' cluster member again, and tried to remove then re-add the secondary address on the other cluster member, but I get the following error: JERS0B::SYSTEM>netcu rem second 194.202.150.33 %TCPWARE_NETCU-F-IVLOCKID, invalid lock ID JERS0B::SYSTEM>netcu rem second 194.202.150.33/abort %TCPWARE_NETCU-F-IVLOCKID, invalid lock ID This happens no matter what the state of the other cluster member (ie with or without the cluster secondary address). I'm a bit concerned that if the node that is holding the address were to fail or be shut down, that I would then no longer have access to the cluster alias address. Does anybody have any ideas what might be causing this ? Regards, Derek... I *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Mon, 19 Apr 1999 07:47:11 -0400 Date: Mon, 19 Apr 1999 12:42:19 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: TCPware V5.2-3 and OpenVMS VAX 7.2 To: support@essential.co.uk, Info-TCPware@process.com Message-ID: <99Apr19.124600bst.14339@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN Hello, TCPware V5.2-3 I have just upgraded my O/S to OpenVMS V7.2 on VAX. I have downloaded the following patches from ftp.process.com as suggested to resolve a possible security problem and to support OpenVMS V7.2 The destination hardware is a MicroVAX 3100-85. DRIVERS_V523P050.A;1 NET_V523P030.A;1 When installing the NET_V523P030 patch I get the following error:- Linking NETCU.EXE %LINK-W-NUDFSYMS, 1 undefined symbol: %LINK-I-UDFSYM, TCPWARE_EXKBYTE %VMSINSTAL-E-INSFAIL, The installation of NET_V523P V3.0 has failed. It seems to install perfectly OK on Alpha. Please advise. TIA /Steve ================================================================================ Archive-Date: Mon, 19 Apr 1999 07:57:34 -0400 From: "Michel A. Herrscher" Reply-To: Info-TCPware@process.com Subject: Re: DEC Printserver 20, LPS print queues Date: Mon, 19 Apr 1999 13:56:35 +0200 Message-ID: <371b19e9@news.iprolink.ch> To: Info-TCPware@PROCESS.COM >You might consider configuring DCPS on the VMS system to send the >data to a particular TCP/IP address and port number (see the TCPware >documentation for details on this). > >- Bernie Volz > Process Software > Bernie, You are right. Printerserver are PS machines and you can print from VMS only with DCPS Michel Herrscher "Do now what you want, Tomorrow you may not be able to do it" ================================================================================ Archive-Date: Mon, 19 Apr 1999 11:07:59 -0400 Sender: schreiber@process.com Date: Mon, 19 Apr 1999 11:08:06 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D6DDD.5D6B9A0E.70@process.com> Subject: RE: TCPware V5.2-3 and OpenVMS VAX 7.2 Steve Wakelin writes: > >TCPware V5.2-3 > >I have just upgraded my O/S to OpenVMS V7.2 on VAX. > Thanks Steve. Can I ask what VMS OS you upgraded from? Did you reinstall TCPware? Can you send me the output of: LIB/LIST/NAMES TCPWARE:SOCKLIB.OLB -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 19 Apr 1999 14:46:49 -0400 Sender: schreiber@process.com Date: Mon, 19 Apr 1999 14:46:56 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D6DFB.EF3F19C4.69@process.com> Subject: RE: TCPware V5.2-3 and OpenVMS VAX 7.2 Steve Wakelin writes: > >When installing the NET_V523P030 patch I get the following >error:- > >Linking NETCU.EXE >%LINK-W-NUDFSYMS, 1 undefined symbol: >%LINK-I-UDFSYM, TCPWARE_EXKBYTE >%VMSINSTAL-E-INSFAIL, The installation of NET_V523P V3.0 has >failed. > Thanks again for finding this Steve. The NET_V523P030 Patch seems to have a dependancy on a version of Socklib a little later than 5.2-3. Try installing SOCKLIB_V523P020 first, then put on the NET_V523P030 Patch. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 19 Apr 1999 16:10:33 -0400 Sender: goatley@triton.process.com Return-Path: Date: Mon, 19 Apr 1999 20:07:43 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: Re: TCPware V5.2-3 and OpenVMS VAX 7.2 In-Reply-To: <009D6DFB.EF3F19C4.69@process.com> X-MX-Warning: Warning -- Invalid "To" header. To: schreiber , Info-TCPware CC: schreiber Message-ID: <99Apr19.200655bst.14337@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN Jeff, Many thanks. That has solved the problem. /Steve ================================================================================ Archive-Date: Mon, 19 Apr 1999 22:29:38 -0400 Subject: Re: Cluster Alias Failover Problem Message-ID: <1999Apr19.221118@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 19 Apr 99 22:11:18 -0500 To: Info-TCPware@PROCESS.COM This sounds like a possible bug? Can you indicate how quickly/frequently this occurs? Did you have a lot of switches between nodes before this happened or does it happen almost immediately? It would be best to report this to our Technical Support folks such that they can open a case on it to collect more information and get it resolved. - Bernie Volz Process Software In article <49B21CD935D0D011B4980000F875254F01753589@RDPEXC01>, Derek Fage writes: > Hi there, > > I've been running some load tests on our cluster (OpenVMS 7.1-1H2 TCPware > 5.3-3) and have come up with a strange error. > > I am trying to get the cluster alias failover address to go onto a different > machine. Normally to do this I would do a NETCU REM SECOND nnn.nnn.nnn.nnn > /ABORT on the node that has the active secondary address, and the other node > that was queueing for the lock would take it. > > In this case it did not take over the lock, it just stayed queued. > > I added the secondary address to the 'primary' cluster member again, and > tried to remove then re-add the secondary address on the other cluster > member, but I get the following error: > > JERS0B::SYSTEM>netcu rem second 194.202.150.33 > %TCPWARE_NETCU-F-IVLOCKID, invalid lock ID > JERS0B::SYSTEM>netcu rem second 194.202.150.33/abort > %TCPWARE_NETCU-F-IVLOCKID, invalid lock ID > > This happens no matter what the state of the other cluster member (ie with > or without the cluster secondary address). > > I'm a bit concerned that if the node that is holding the address were to > fail or be shut down, that I would then no longer have access to the cluster > alias address. > > Does anybody have any ideas what might be causing this ? > > Regards, > > Derek... ================================================================================ Archive-Date: Tue, 20 Apr 1999 14:27:54 -0400 From: "howard gillison" Reply-To: Info-TCPware@process.com Subject: automatic logins Date: Tue, 20 Apr 1999 14:17:20 -0400 Message-ID: <7figbq$r4k$1@mach1.gvltec.edu> To: Info-TCPware@PROCESS.COM perhaps someone here will know this. I'm running Ovms V7.1 with TCPware V5.2-3. Is there a way/method to allow for "automatic logins" using the ALF utility with a PC connected via TCP/IP? It seems that I've seen this documented on one occasion and you can actually do it...but you have some special steps to do before it will work....or am I beating my head on a wall? any responses..please mail me at: Howard@gvltec.edu thanks and have a good day ================================================================================ Archive-Date: Wed, 21 Apr 1999 06:05:27 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: NTP request and questions Date: Wed, 21 Apr 1999 10:28:32 +0100 Message-ID: <7fk5le$il5$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM Config: TCPware V5.5-2 (plus all patches) running under OpenVMS VAX and Alpha V6.2 and V6.2-1H3. Further to a couple of the previous entries on NTP and time change etc. I edited SYSTARTUP_VMS.COM to include the following when starting up TCPware to ensure the correct timezone setting. Note that the timezone is worked out and set in TCPWARE:ROUTING.COM $ write sys$output f$fao("!/!8%T!_Starting TCPware...",0) $ @sys$common:[tcpware]tcpware_logicals $ @tcpware:startnet $ if f$search("tcpware:ntpdate.exe") .nes. "" $ then ntpdate = "$tcpware:ntpdate" $ write sys$output f$fao("!/!8%T!_Verifying NTP date/time...",0) $ @tcpware:shutnet ntp $ ntpdate "-bs" xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy $ @tcpware:startnet ntp $ endif All pretty much OK. The STARTNET starts everything necessary & then we kill the NTP daemon, force the clock right and then restart the daemon. However, a couple of times I've been in the situation where (for whatever reason) the time servers weren't available. Unfortunately, once NTPDATE gets going it refuses to give up. The system startup effectively hung at this point & we had to reboot minimum etc. So, the request is : Is there any way I can get NTPDATE to "time out" so the procedure continues ? The alternative is to build a whole great procedure that runs PING_V2 to ping each server (only PING_V2 accepts a timeout parameter) before NTPDATEing. Would it be a lot of work to include timeout functionality within NTPDATE ? OK, now the questions: 1. Does anyone know where generic information/documentation on NTP resides on the net ? 2. At what delta value does NTP decide to "adjust" (ie. step or slew) the system clock ? I just shut the NTP daemon down on my workstation (uptime was a few months) & ran NTPDATE and was surprised to see that NTPDATE pulled the clock back by just over 9 seconds. 3. What determines the frequency of how often the NTP daemon acquires the time servers to check the time setting ? 4. If the timezone is changed while the NTP daemon is running should the time be altered ? When the clocks moved forward the operators here simply did a SET TIMEZONE +0100 on the systems and several hours later the clocks hadn't advanced despite the timeservers being acquired several times. This was the reason for the additional code in SYSTARTUP_VMS. Thanks for any help, Cheers, -Andy ================================================================================ Archive-Date: Wed, 21 Apr 1999 06:21:29 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Re: NTP request and questions Date: Wed, 21 Apr 1999 10:44:06 +0100 Message-ID: <7fk6ik$o6u$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM Andy Williams wrote in message news:7fk5le$il5$1@gatekeeper.liffe.com... > Config: TCPware V5.5-2 (plus all patches) running under OpenVMS VAX and Oops ! I meant TCPware V5.3-2 of course ! I'll blame it for having to do work on a few VAX V5.5-2 systems ;-) -Andy ================================================================================ Archive-Date: Wed, 21 Apr 1999 07:45:25 -0400 Message-ID: <003401be8bec$463195b0$150110ac@pcmv.pdv.intern> Reply-To: Info-TCPware@process.com From: "Martin Vorlaender" To: Subject: Re: NTP request and questions Date: Wed, 21 Apr 1999 13:43:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >1. Does anyone know where generic information/documentation on NTP resides >on the net ? http://www.eecis.udel.edu/~ntp/ has lots of information and links. 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: Wed, 21 Apr 1999 14:45:04 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017535DD@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: FTP problems Date: Wed, 21 Apr 1999 19:47:00 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE8C26.F133BB50" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE8C26.F133BB50 Content-Type: text/plain Hi there, We have had a strange problem since installing TCPware over the weekend when we FTP a file to a remote unix system The file transfer appears to stall and then timeout. This is going over Cisco routers and leased lines, through a firewall (that we have no control over), and onto a Unix system. We transmit 2 zipped files - each approx 1.5 Mb in size. One file transfers fine, the other fails. These two files are created each day, and if I try sending a copy of the one that failed that was transmitted OK using UCX last week, it fails again. FTPing to a local Solaris system gives me no problems. The strange thing is it is a single customer (out of about 30 we FTP files to), and a single service (out of the two we transfer each day) that is giving us problems. We have asked them to look into if their FireWall is logging anything, and I have also tried MGFTP client, but I still get the same problem. Has anybody seen this before, or can anybody give me any pointers ? Here's output of FTP JERS0B::SYSTEM>define ftp_startup dftest.tmp %DCL-I-SUPERSEDE, previous value of FTP_STARTUP has been superseded JERS0B::SYSTEM>ftp 220 serin FTP server (UNIX(r) System V Release 4.0) ready. 331 Password required for ftiftp3. 230 User ftiftp3 logged in. 200 Type set to I. 200 PORT command successful. 150 Binary data connection for test1.srv.gz (194.202.150.35,42832). ############################################################################ #### ############################################################################ #### ############################################################################ #### ############################################################################ #### ############################################################################ #### ############################################################################ #### ############################################################################ #### ##################################################################### 552 test1.srv.gz: Connection reset by peer. %TCPWARE_FTP-E-FILRDERR, error reading from or sending FTS$SERVICES:[U16188.N161 88]19990420.ZIP_SAVED;1 -SYSTEM-F-TIMEOUT, device timeout I have also attached a cut down version of start and end of transfer from TCPDUMP if anybody can make any sense of it. I'm really after some pointers on where to go from here (I've tried using PASSIVE and NOPASIVE). Cheers, Derek... <> This problem causes has meant that I have been called at 2AM to investigate for the last two nights (the first night I thought it was disk space problems and left it). 8-( *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ------_=_NextPart_000_01BE8C26.F133BB50 Content-Type: text/plain; name="ftp probs.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ftp probs.txt" 19:18:23.293096 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: S = 562013460:562013460(0) win 24576 (DF) 19:18:23.368286 194.61.105.77.ftp > jers0b.itexhld.com.42831: S = 2093401599:2093401599(0) ack 562013461 win 8760 (DF) 19:18:23.368286 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . ack 1 = win 24576 (DF) 19:18:23.500114 194.61.105.77.ftp > jers0b.itexhld.com.42831: P = 1:61(60) ack 1 win 8760 (DF) 19:18:23.502067 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: P = 1:15(14) ack 61 win 24576 (DF) 19:18:23.631941 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 15 = win 8760 (DF) 19:18:23.873137 194.61.105.77.ftp > jers0b.itexhld.com.42831: P = 61:97(36) ack 15 win 8760 (DF) 19:18:23.873137 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: P = 15:29(14) ack 97 win 24576 (DF) 19:18:23.995199 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 29 = win 8760 (DF) 19:18:24.655313 194.61.105.77.ftp > jers0b.itexhld.com.42831: P = 97:126(29) ack 29 win 8760 (DF) 19:18:24.656290 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: P = 29:37(8) ack 126 win 24576 (DF) 19:18:24.727574 194.61.105.77.ftp > jers0b.itexhld.com.42831: P = 126:146(20) ack 37 win 8760 (DF) 19:18:24.746128 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: P = 37:65(28) ack 146 win 24576 (DF) 19:18:24.837919 194.61.105.77.ftp > jers0b.itexhld.com.42831: P = 146:176(30) ack 65 win 8760 (DF) 19:18:24.838895 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: P = 65:84(19) ack 176 win 24576 (DF) 19:18:24.927757 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: S = 2093823644:2093823644(0) win 24820 (DF) 19:18:24.928733 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: S = 562524597:562524597(0) ack 2093823645 win 32768 (DF) 19:18:24.964864 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:18:24.993182 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 1 win 24820 (DF) 19:18:25.017595 194.61.105.77.ftp > jers0b.itexhld.com.42831: P = 176:245(69) ack 84 win 8760 (DF) 19:18:25.042984 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: P = 1:1025(1024) ack 1 win 32768 (DF) 19:18:25.043960 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 1025:2485(1460) ack 1 win 32768 (DF) 19:18:25.043960 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 2485:3945(1460) ack 1 win 32768 (DF) 19:18:25.191412 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . ack 245 = win 24576 (DF) 19:18:25.454090 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 1025 win 24820 (DF) 19:18:25.454090 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 3945:5405(1460) ack 1 win 32768 (DF) 19:18:25.454090 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 5405:6865(1460) ack 1 win 32768 (DF) 19:18:25.662085 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 2485 win 24820 (DF) 19:18:25.662085 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 6865:8325(1460) ack 1 win 32768 (DF) 19:18:25.662085 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 8325:9785(1460) ack 1 win 32768 (DF) 19:18:25.944293 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 3945 win 24820 (DF) 19:18:25.944293 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 9785:11245(1460) ack 1 win 32768 (DF) 19:18:25.944293 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 11245:12705(1460) ack 1 win 32768 (DF) 19:18:26.143499 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 5405 win 24820 (DF) 19:18:26.143499 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 12705:14165(1460) ack 1 win 32768 (DF) 19:18:26.143499 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 14165:15625(1460) ack 1 win 32768 (DF) 19:18:26.333917 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 6865 win 24820 (DF) 19:18:26.333917 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 15625:17085(1460) ack 1 win 32768 (DF) 19:18:26.333917 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 17085:18545(1460) ack 1 win 32768 (DF) 19:18:26.541911 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 8325 win 24820 (DF) 19:18:26.542888 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 18545:20005(1460) ack 1 win 32768 (DF) 19:18:26.542888 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 20005:21465(1460) ack 1 win 32768 (DF) 19:18:26.713775 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 9785 win 24820 (DF) . . . . . . 19:19:43.112323 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:19:43.312506 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 587945 win 24820 (DF) 19:19:43.312506 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 611305:612765(1460) ack 1 win 32768 (DF) 19:19:43.501947 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 589405 win 24820 (DF) 19:19:43.501947 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 612765:614225(1460) ack 1 win 32768 (DF) 19:19:43.731424 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 590865 win 24820 (DF) 19:19:43.731424 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 614225:615685(1460) ack 1 win 32768 (DF) 19:19:43.889617 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 592325 win 24820 (DF) 19:19:43.889617 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 615685:617145(1460) ack 1 win 32768 (DF) 19:19:44.081988 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 593785 win 24820 (DF) 19:19:44.081988 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 617145:618605(1460) ack 1 win 32768 (DF) 19:19:44.261664 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 595245 win 24820 (DF) 19:19:44.261664 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 618605:620065(1460) ack 1 win 32768 (DF) 19:19:44.457940 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 596705 win 24820 (DF) 19:19:44.457940 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 620065:621525(1460) ack 1 win 32768 (DF) 19:19:44.687418 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 598165 win 24820 (DF) 19:19:44.687418 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 621525:622985(1460) ack 1 win 32768 (DF) 19:19:44.841705 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 599625 win 24820 (DF) 19:19:44.841705 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 622985:624445(1460) ack 1 win 32768 (DF) 19:19:45.031146 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 601085 win 24820 (DF) 19:19:45.031146 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 624445:625905(1460) ack 1 win 32768 (DF) 19:19:45.222813 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 602545 win 24820 (DF) 19:19:45.222813 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 625905:627365(1460) ack 1 win 32768 (DF) 19:19:45.413231 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 604005 win 24820 (DF) 19:19:45.413231 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 627365:628825(1460) ack 1 win 32768 (DF) 19:19:45.603648 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 605465 win 24820 (DF) 19:19:45.603648 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 628825:630285(1460) ack 1 win 32768 (DF) 19:19:45.802854 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 606925 win 24820 (DF) 19:19:45.802854 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 630285:631745(1460) ack 1 win 32768 (DF) 19:19:45.993272 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 608385 win 24820 (DF) 19:19:45.993272 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 631745:633205(1460) ack 1 win 32768 (DF) 19:19:46.182713 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:46.182713 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 633205:634665(1460) ack 1 win 32768 (DF) 19:19:46.464921 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:46.652409 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:46.854545 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:47.037150 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:47.233427 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:47.423844 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:47.612309 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:47.803703 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:47.995097 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:48.184538 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:48.376908 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:48.575138 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:48.767508 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:48.957926 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:49.139555 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:49.334855 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . = ack 609845 win 24820 (DF) 19:19:49.896342 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:19:57.505230 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:20:12.723280 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:20:43.156176 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:20:57.975813 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 245 win 24576 (DF) 19:20:58.044168 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:21:44.028374 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:22:13.063898 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 245 win 24576 (DF) 19:22:13.127371 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:22:46.102370 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:23:28.151983 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 245 win 24576 (DF) 19:23:28.214479 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:23:48.178319 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:24:43.243974 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 245 win 24576 (DF) 19:24:43.312329 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:24:50.252315 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:25:52.328264 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:25:58.336942 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 245 win 24576 (DF) 19:25:58.401391 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:26:54.400307 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . = 609845:611305(1460) ack 1 win 32768 (DF) 19:27:13.421824 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 245 win 24576 (DF) 19:27:13.492132 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:27:46.660478 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: R = 563135902:563135902(0) win 24576 19:27:46.739574 194.61.105.77.ftp > jers0b.itexhld.com.42831: P = 245:290(45) ack 84 win 8760 (DF) 19:27:46.860660 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . ack 290 = win 24576 (DF) 19:29:01.751492 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 290 win 24576 (DF) 19:29:01.814965 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) 19:30:16.833718 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . = 83:84(1) ack 290 win 24576 (DF) 19:30:16.896214 194.61.105.77.ftp > jers0b.itexhld.com.42831: . ack 84 = win 8760 (DF) ------_=_NextPart_000_01BE8C26.F133BB50-- ================================================================================ Archive-Date: Thu, 22 Apr 1999 04:23:36 -0400 Date: Thu, 22 Apr 1999 09:08:45 +0100 From: "Raymond, David" Reply-To: Info-TCPware@process.com Subject: RE: FTP problems To: "'Info-TCPware@process.com'" Message-ID: <90088CB087DBD21194870008C733B45D048BE6@NTESS005> MIME-Version: 1.0 Content-Type: text/plain Derek, I've no immediate ideas of the cause, but other info that might help me or others diagnose the problem is... >JERS0B::SYSTEM>define ftp_startup dftest.tmp A copy of dftest.tmp to see what startup commands are being used >I have also attached a cut down version of start and end of >transfer from >TCPDUMP if anybody can make any sense of it. The output from NETCU DEBUG would be more useful, eg $ NETCU DEBUG /TCP/DIA=194.202.150.35/DATA=128/OUTPUT= Regards David ================================================================================ Archive-Date: Thu, 22 Apr 1999 05:22:19 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: FTP problems Date: 22 Apr 1999 11:20:46 +0100 Message-ID: <371ee9ee.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F017535DD@RDPEXC01>, Derek Fage writes: >We have had a strange problem since installing TCPware over the weekend when >we FTP a file to a remote unix system We have a lot more FTP aborts with TCPware than with UCX. Still don't know why (maybe timeout value is smaller than in UCX), but didn't do many tests, so far. So no complaint/service call... >The file transfer appears to stall and then timeout. This is going over >Cisco routers and leased lines, through a firewall (that we have no control >over), and onto a Unix system. In our case, it is first the firewall, then the CISCO router to the ISP. But I don't think, this is important. >We transmit 2 zipped files - each approx 1.5 Mb in size. One file transfers >fine, the other fails. These two files are created each day, and if I try >sending a copy of the one that failed that was transmitted OK using UCX last >week, it fails again. FTPing to a local Solaris system gives me no problems. >The strange thing is it is a single customer (out of about 30 we FTP files >to), and a single service (out of the two we transfer each day) that is >giving us problems. > >We have asked them to look into if their FireWall is logging anything, and I >have also tried MGFTP client, but I still get the same problem. > >Has anybody seen this before, or can anybody give me any pointers ? We also had a lot of problems with downloading _some_ files. It mostly turned out to be the remote FTP server. Other FTP clients on another opsys couldn't download the files, too. And it aborted at approx. the same size. >I'm really after some pointers on where to go from here (I've tried using >PASSIVE and NOPASIVE). Didn't make a difference in our case either. But changing TCPware to UCX didn't solve it, too, because, as I wrote, it mostly was a remote problem. ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 22 Apr 1999 05:43:45 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017535F9@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: FTP problems Date: Thu, 22 Apr 1999 10:34:07 +0100 MIME-Version: 1.0 Content-Type: text/plain Cheers Peter, We're now getting more and more convinced it is the FireWall. Derek... > -----Original Message----- > From: eplan@kapsch.net [SMTP:eplan@kapsch.net] > Sent: 22 April 1999 11:21 > To: Info-TCPware@PROCESS.COM > Subject: Re: FTP problems > > In article <49B21CD935D0D011B4980000F875254F017535DD@RDPEXC01>, Derek Fage > writes: > >We have had a strange problem since installing TCPware over the weekend > when > >we FTP a file to a remote unix system > > We have a lot more FTP aborts with TCPware than with UCX. Still don't know > why (maybe timeout value is smaller than in UCX), but didn't do many > tests, > so far. So no complaint/service call... > > >The file transfer appears to stall and then timeout. This is going over > >Cisco routers and leased lines, through a firewall (that we have no > control > >over), and onto a Unix system. > > In our case, it is first the firewall, then the CISCO router to the ISP. > But I don't think, this is important. > > >We transmit 2 zipped files - each approx 1.5 Mb in size. One file > transfers > >fine, the other fails. These two files are created each day, and if I try > >sending a copy of the one that failed that was transmitted OK using UCX > last > >week, it fails again. FTPing to a local Solaris system gives me no > problems. > >The strange thing is it is a single customer (out of about 30 we FTP > files > >to), and a single service (out of the two we transfer each day) that is > >giving us problems. > > > >We have asked them to look into if their FireWall is logging anything, > and I > >have also tried MGFTP client, but I still get the same problem. > > > >Has anybody seen this before, or can anybody give me any pointers ? > > We also had a lot of problems with downloading _some_ files. It mostly > turned out to be the remote FTP server. Other FTP clients on another opsys > couldn't download the files, too. And it aborted at approx. the same size. > > >I'm really after some pointers on where to go from here (I've tried using > >PASSIVE and NOPASIVE). > > Didn't make a difference in our case either. But changing TCPware to UCX > didn't solve it, too, because, as I wrote, it mostly was a remote problem. > > ------------------------------------------------------------------------ > Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 > Network and OpenVMS system manager Fax. +43 1 81111-888 > FBFV/Information Services E-mail eplan@kapsch.net > <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN > A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" > "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, > 22-Sep-1998 *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 22 Apr 1999 07:51:08 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753604@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: Telnet user accounting info Date: Thu, 22 Apr 1999 12:50:29 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, Does anybody know how to get TCPware to populate the remote node addr, remote node name and remote ID in the accounting record for telnet interactive connections ? It used to work with UCX, but not with Telnet, and we need this information for billing / accounting purposes. INTERACTIVE Process Termination ------------------------------- Username: U99100 UIC: [USERS,U99100] Account: USERS Finish time: 22-APR-1999 11:36:33.49 Process ID: 20491A2C Start time: 22-APR-1999 11:36:21.81 Owner ID: Elapsed time: 0 00:00:11.67 Terminal name: NTA11: Processor time: 0 00:00:00.29 Remote node addr: Priority: 4 Remote node name: Privilege <31-00>: 00108000 Remote ID: Privilege <63-32>: 00000000 Remote full name: Queue entry: Final status code: 10000001 Queue name: Job name: Final status text: %SYSTEM-S-NORMAL, normal successful completion Page faults: 636 Direct IO: 94 Page fault reads: 99 Buffered IO: 250 Peak working set: 2816 Volumes mounted: 0 Peak page file: 169264 Images executed: 7 I used to have this functionality with UCX: INTERACTIVE Process Termination ------------------------------- Username: U99100 UIC: [USERS,U99100] Account: USERS Finish time: 12-APR-1999 15:49:17.77 Process ID: 2060909B Start time: 12-APR-1999 15:45:35.31 Owner ID: Elapsed time: 0 00:03:42.46 Terminal name: TNA2899 Processor time: 0 00:00:01.60 Remote node addr: 31709 Priority: 4 Remote node name: nicks_ Privilege <31-00>: 00108000 Remote ID: TELNET_BD0102F1 Privilege <63-32>: 00000000 Remote full name: Queue entry: Final status code: 10000001 Queue name: Job name: Final status text: %SYSTEM-S-NORMAL, normal successful completion Page faults: 2329 Direct IO: 796 Page fault reads: 397 Buffered IO: 1377 Peak working set: 2832 Volumes mounted: 0 Peak page file: 169552 Images executed: 21 *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 22 Apr 1999 10:25:28 -0400 Message-ID: <371F3151.388F8F74@process.com> Date: Thu, 22 Apr 1999 10:25:21 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@mx.process.com Subject: RE: FTP problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi there, > > We have had a strange problem since installing TCPware over the weekend when > we FTP a file to a remote unix system > > The file transfer appears to stall and then timeout. This is going over > Cisco routers and leased lines, through a firewall (that we have no control > over), and onto a Unix system. > > We transmit 2 zipped files - each approx 1.5 Mb in size. One file transfers > fine, the other fails. These two files are created each day, and if I try > sending a copy of the one that failed that was transmitted OK using UCX last > week, it fails again. FTPing to a local Solaris system gives me no problems. > The strange thing is it is a single customer (out of about 30 we FTP files > to), and a single service (out of the two we transfer each day) that is > giving us problems. > > We have asked them to look into if their FireWall is logging anything, and I > have also tried MGFTP client, but I still get the same problem. > > Has anybody seen this before, or can anybody give me any pointers ? > > Here's output of FTP > > JERS0B::SYSTEM>define ftp_startup dftest.tmp > %DCL-I-SUPERSEDE, previous value of FTP_STARTUP has been superseded > JERS0B::SYSTEM>ftp > 220 serin FTP server (UNIX(r) System V Release 4.0) ready. > 331 Password required for ftiftp3. > 230 User ftiftp3 logged in. > 200 Type set to I. > 200 PORT command successful. > 150 Binary data connection for test1.srv.gz (194.202.150.35,42832). > ############################################################################ [SNIP] > 552 test1.srv.gz: Connection reset by peer. > %TCPWARE_FTP-E-FILRDERR, error reading from or sending > FTS$SERVICES:[U16188.N161 > 88]19990420.ZIP_SAVED;1 > -SYSTEM-F-TIMEOUT, device timeout > > I have also attached a cut down version of start and end of transfer from > TCPDUMP if anybody can make any sense of it. > > I'm really after some pointers on where to go from here (I've tried using > PASSIVE and NOPASIVE). > Here is the TCPDUMP the part of the TCPDUMP that shows what is going wrong [I've taken out the segments on the FTP port and left just the ones for the ftp-data port.] 19:19:49.334855 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . ack 609845 win 24820 (DF) 19:19:49.896342 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:19:57.505230 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:20:12.723280 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:20:43.156176 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:21:44.028374 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:22:46.102370 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:23:48.178319 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:24:50.252315 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:25:52.328264 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:26:54.400307 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:27:46.660478 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: R 563135902:563135902(0) win 24576 At 19:19:49 194.161.105.77 ACKs 609845 so then jers0b sends the next 1460 bytes of TCP data (bytes 609845:611305). This never gets ACKed by 194.61.105.77 so it retransmits it again, and again, and again, until finally it gives up and resets the connection at 19:27:46. What is interesting is the following segments from the TCPDUMP right after the reset - 19:27:46.739574 194.61.105.77.ftp > jers0b.itexhld.com.42831: P 245:290(45) ack 84 win 8760 (DF) 19:27:46.860660 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . ack 290 win 24576 (DF) 19:29:01.751492 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . 83:84(1) ack 290 win 24576 (DF) Both systems still have the FTP connection established and are receiving data over it. So the question is why does the ftp-data segment that is sent never get acknowledged? My guess would be the firewall is dropping it or the ACK for it. Hope that helps. 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: Thu, 22 Apr 1999 10:25:33 -0400 Message-ID: <371F3155.5201F89C@process.com> Date: Thu, 22 Apr 1999 10:25:25 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@mx.process.com Subject: RE: FTP problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi there, > > We have had a strange problem since installing TCPware over the weekend when > we FTP a file to a remote unix system > > The file transfer appears to stall and then timeout. This is going over > Cisco routers and leased lines, through a firewall (that we have no control > over), and onto a Unix system. > > We transmit 2 zipped files - each approx 1.5 Mb in size. One file transfers > fine, the other fails. These two files are created each day, and if I try > sending a copy of the one that failed that was transmitted OK using UCX last > week, it fails again. FTPing to a local Solaris system gives me no problems. > The strange thing is it is a single customer (out of about 30 we FTP files > to), and a single service (out of the two we transfer each day) that is > giving us problems. > > We have asked them to look into if their FireWall is logging anything, and I > have also tried MGFTP client, but I still get the same problem. > > Has anybody seen this before, or can anybody give me any pointers ? > > Here's output of FTP > > JERS0B::SYSTEM>define ftp_startup dftest.tmp > %DCL-I-SUPERSEDE, previous value of FTP_STARTUP has been superseded > JERS0B::SYSTEM>ftp > 220 serin FTP server (UNIX(r) System V Release 4.0) ready. > 331 Password required for ftiftp3. > 230 User ftiftp3 logged in. > 200 Type set to I. > 200 PORT command successful. > 150 Binary data connection for test1.srv.gz (194.202.150.35,42832). > ############################################################################ [SNIP] > 552 test1.srv.gz: Connection reset by peer. > %TCPWARE_FTP-E-FILRDERR, error reading from or sending > FTS$SERVICES:[U16188.N161 > 88]19990420.ZIP_SAVED;1 > -SYSTEM-F-TIMEOUT, device timeout > > I have also attached a cut down version of start and end of transfer from > TCPDUMP if anybody can make any sense of it. > > I'm really after some pointers on where to go from here (I've tried using > PASSIVE and NOPASIVE). > Here is the TCPDUMP the part of the TCPDUMP that shows what is going wrong [I've taken out the segments on the FTP port and left just the ones for the ftp-data port.] 19:19:49.334855 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . ack 609845 win 24820 (DF) 19:19:49.896342 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:19:57.505230 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:20:12.723280 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:20:43.156176 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:21:44.028374 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:22:46.102370 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:23:48.178319 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:24:50.252315 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:25:52.328264 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:26:54.400307 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . 609845:611305(1460) ack 1 win 32768 (DF) 19:27:46.660478 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: R 563135902:563135902(0) win 24576 At 19:19:49 194.161.105.77 ACKs 609845 so then jers0b sends the next 1460 bytes of TCP data (bytes 609845:611305). This never gets ACKed by 194.61.105.77 so it retransmits it again, and again, and again, until finally it gives up and resets the connection at 19:27:46. What is interesting is the following segments from the TCPDUMP right after the reset - 19:27:46.739574 194.61.105.77.ftp > jers0b.itexhld.com.42831: P 245:290(45) ack 84 win 8760 (DF) 19:27:46.860660 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . ack 290 win 24576 (DF) 19:29:01.751492 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . 83:84(1) ack 290 win 24576 (DF) Both systems still have the FTP connection established and are receiving data over it. So the question is why does the ftp-data segment that is sent never get acknowledged? My guess would be the firewall is dropping it or the ACK for it. Hope that helps. 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: Thu, 22 Apr 1999 10:41:32 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0175360A@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: FTP problems Date: Thu, 22 Apr 1999 15:34:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Michael, Thanks for the additional info. I'm also think it's the FireWall, but the customer keeps saying that nothing has changed at their end, and the problems only occured since we upgraded the stack. I've convinced them to add a new rul allowing some additional hosts on our site FTP access, and we'll try FTPing the file from a UCX box and a Solaris box to establish exactly what is happening. Cheers, Derek... > -----Original Message----- > From: Michael Corbett [SMTP:corbett@process.com] > Sent: 22 April 1999 15:25 > To: info-tcpware@mx.process.com > Subject: RE: FTP problems > > > Hi there, > > > > We have had a strange problem since installing TCPware over the weekend > when > > we FTP a file to a remote unix system > > > > The file transfer appears to stall and then timeout. This is going over > > Cisco routers and leased lines, through a firewall (that we have no > control > > over), and onto a Unix system. > > > > We transmit 2 zipped files - each approx 1.5 Mb in size. One file > transfers > > fine, the other fails. These two files are created each day, and if I > try > > sending a copy of the one that failed that was transmitted OK using UCX > last > > week, it fails again. FTPing to a local Solaris system gives me no > problems. > > The strange thing is it is a single customer (out of about 30 we FTP > files > > to), and a single service (out of the two we transfer each day) that is > > giving us problems. > > > > We have asked them to look into if their FireWall is logging anything, > and I > > have also tried MGFTP client, but I still get the same problem. > > > > Has anybody seen this before, or can anybody give me any pointers ? > > > > Here's output of FTP > > > > JERS0B::SYSTEM>define ftp_startup dftest.tmp > > %DCL-I-SUPERSEDE, previous value of FTP_STARTUP has been superseded > > JERS0B::SYSTEM>ftp > > 220 serin FTP server (UNIX(r) System V Release 4.0) ready. > > 331 Password required for ftiftp3. > > 230 User ftiftp3 logged in. > > 200 Type set to I. > > 200 PORT command successful. > > 150 Binary data connection for test1.srv.gz (194.202.150.35,42832). > > > ########################################################################## > ## > [SNIP] > > 552 test1.srv.gz: Connection reset by peer. > > %TCPWARE_FTP-E-FILRDERR, error reading from or sending > > FTS$SERVICES:[U16188.N161 > > 88]19990420.ZIP_SAVED;1 > > -SYSTEM-F-TIMEOUT, device timeout > > > > I have also attached a cut down version of start and end of transfer > from > > TCPDUMP if anybody can make any sense of it. > > > > I'm really after some pointers on where to go from here (I've tried > using > > PASSIVE and NOPASIVE). > > > > Here is the TCPDUMP the part of the TCPDUMP that shows what is going > wrong [I've taken out the segments on the FTP port and left just the > ones for the ftp-data port.] > > 19:19:49.334855 194.61.105.77.ftp-data > jers0b.itexhld.com.42832: . ack > 609845 win 24820 (DF) > 19:19:49.896342 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:19:57.505230 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:20:12.723280 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:20:43.156176 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:21:44.028374 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:22:46.102370 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:23:48.178319 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:24:50.252315 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:25:52.328264 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:26:54.400307 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: . > 609845:611305(1460) ack 1 win 32768 (DF) > 19:27:46.660478 jers0b.itexhld.com.42832 > 194.61.105.77.ftp-data: R > 563135902:563135902(0) win 24576 > > At 19:19:49 194.161.105.77 ACKs 609845 so then jers0b sends the next 1460 > bytes of TCP data (bytes 609845:611305). This never gets ACKed by > 194.61.105.77 so it retransmits it again, and again, and again, until > finally it gives up and resets the connection at 19:27:46. What is > interesting is the following segments from the TCPDUMP right after > the reset - > > 19:27:46.739574 194.61.105.77.ftp > jers0b.itexhld.com.42831: P > 245:290(45) ack 84 win 8760 (DF) > 19:27:46.860660 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . ack 290 > win 24576 (DF) > 19:29:01.751492 jers0b.itexhld.com.42831 > 194.61.105.77.ftp: . 83:84(1) > ack 290 win 24576 (DF) > > Both systems still have the FTP connection established and are receiving > data over it. So the question is why does the ftp-data segment that > is sent never get acknowledged? My guess would be the firewall is > dropping it or the ACK for it. > > Hope that helps. > > 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 *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 22 Apr 1999 12:35:10 -0400 Date: Thu, 22 Apr 1999 15:29:57 +0100 From: "Raymond, David" Reply-To: Info-TCPware@process.com Subject: Synchronising VMS time To: "'info-tcpware@process.com'" Message-ID: <90088CB087DBD21194870008C733B45D048BF1@NTESS005> MIME-Version: 1.0 Content-Type: text/plain We have a customer who is looking to synchronise their VMS TCPware systems using NTP and they want to have one VMS system as the master server linked to an appropriate clock. I know enough about the NTP side of things, but we have no experience of appropriate clock hardware to connect to VMS systems. We would be interested to know what other sites use, along with and pros & cons of the solution they have implemented. Any suggestions? Regards David ================================================================================ Archive-Date: Thu, 22 Apr 1999 13:13:30 -0400 From: lshepherd@lortobco.com Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <8525675B.005F23FE.00@TCPSMTP.loews.com> Date: Thu, 22 Apr 1999 13:11:37 -0400 Subject: Re: Synchronising VMS time MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii David, I use the TCPWare NTP process to synchronize about 10-15 Vax's to a master clock. I have a stratum 1 GPS reciever that we sync to. You can designate one Vax as the master time source and then sync all the rest to it. NTP on TCPWare is not that hard to set up. The files are about the same as the Unix version of NTP. In the TCPWare documentation, it discusses various levels of synching. You could use a master vax as the official time, and use some others as a middle level that all the rest get their time from. later... luke "Raymond, David" on 04/22/99 10:29:57 AM Please respond to Info-TCPware@process.com To: "'info-tcpware@process.com'" cc: (bcc: Luke Shepherd/Lorillard/MLBA) Subject: Synchronising VMS time We have a customer who is looking to synchronise their VMS TCPware systems using NTP and they want to have one VMS system as the master server linked to an appropriate clock. I know enough about the NTP side of things, but we have no experience of appropriate clock hardware to connect to VMS systems. We would be interested to know what other sites use, along with and pros & cons of the solution they have implemented. Any suggestions? Regards David ================================================================================ Archive-Date: Thu, 22 Apr 1999 13:32:08 -0400 Subject: Re: FTP problems Message-ID: <1999Apr22.122818@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 22 Apr 99 12:28:18 -0500 To: Info-TCPware@PROCESS.COM In article <371ee9ee.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: > In article <49B21CD935D0D011B4980000F875254F017535DD@RDPEXC01>, Derek Fage writes: >>We have had a strange problem since installing TCPware over the weekend when >>we FTP a file to a remote unix system > > We have a lot more FTP aborts with TCPware than with UCX. Still don't know > why (maybe timeout value is smaller than in UCX), but didn't do many tests, > so far. So no complaint/service call... > TCPware uses 8 minutes for the timeout on the data connection. However, I don't think that is the issue since communication is possible during the retransmission time (as evidenced by the control connection having traffic). I've analyzed traces from Derek that he sent me privately. Several potential causes might be: - Data contents. If a firewall is monitoring the data being sent, perhaps the data pattern is triggering virus detection or other condition that results in the connection being "blocked". - Checksum calculations. If the checksum calculation is being done wrong on one of the systems, it could cause this problem. It might be the particular pattern of data that causes a very subtle edge case to be triggered in the calculation/validation routine. From what Derek has said, he's tried several different compression techniques, so it seems likely that these would all produce the same data set. Not sure if he's tried no compression or perhaps uuencode or some other encoding format. - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 22 Apr 1999 13:32:12 -0400 Subject: Re: Telnet user accounting info Message-ID: <1999Apr22.124125@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 22 Apr 99 12:41:25 -0500 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F01753604@RDPEXC01>, Derek Fage writes: > Hi there, > > Does anybody know how to get TCPware to populate the remote node addr, > remote node name and remote ID in the accounting record for telnet > interactive connections ? It used to work with UCX, but not with Telnet, and > we need this information for billing / accounting purposes. > This is something that we've been meaning to add but haven't (basically the P1 space fields for these locations need to be filled in in the created process). If you change the configuration such that TELNET sessions are treated as local, instead of remote, you can sometimes get more information (in OPCOM messages, etc) as the "access port" information is included. See TELNET_CONTROL.COM. You can, of course, pull information out of NETCP.LOG. But that is more complex. - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 22 Apr 1999 14:02:51 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0175360F@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Telnet user accounting info Date: Thu, 22 Apr 1999 18:58:33 +0100 MIME-Version: 1.0 Content-Type: text/plain Hmmm. We've built a billing / MIS system around processing the accounting records to populate our billing / stats databases. We need to know the remote location for these records as certain remote devices get billed premium rates for connect times. I've built a short term workaround where the sylogin.com will write a log record with the information we require, and when we process the accounting file we need to also process this other log file and match them up. How do I go about making a request to get the P1 space fields created for this process, or can we run a program in sylogin.com that will populate them for us ? Derek... > -----Original Message----- > From: volz@process.com [SMTP:volz@process.com] > Sent: 22 April 1999 18:41 > To: Info-TCPware@PROCESS.COM > Subject: Re: Telnet user accounting info > > In article <49B21CD935D0D011B4980000F875254F01753604@RDPEXC01>, Derek Fage > writes: > > Hi there, > > > > Does anybody know how to get TCPware to populate the remote node addr, > > remote node name and remote ID in the accounting record for telnet > > interactive connections ? It used to work with UCX, but not with Telnet, > and > > we need this information for billing / accounting purposes. > > > > This is something that we've been meaning to add but haven't (basically > the P1 space fields for these locations need to be filled in in the > created process). > > If you change the configuration such that TELNET sessions are treated as > local, instead of remote, you can sometimes get more information (in > OPCOM messages, etc) as the "access port" information is included. See > TELNET_CONTROL.COM. > > You can, of course, pull information out of NETCP.LOG. But that is more > complex. > > - Bernie Volz > Process Software *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 22 Apr 1999 14:17:15 -0400 Message-ID: <371F682A.B726FC57@mmaz.com> Date: Thu, 22 Apr 1999 11:19:22 -0700 From: Barry Treahy Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Telnet user accounting info References: <49B21CD935D0D011B4980000F875254F0175360F@RDPEXC01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Derek,why don't you write a brief program using $SNDJBCW when they log in to record the related data into the accountng.dat file in a user defined record? This is what I had to do to capture login sources that were not typically supported by the VMS accounting system... Barry Derek Fage wrote: > Hmmm. > > We've built a billing / MIS system around processing the accounting records > to populate our billing / stats databases. We need to know the remote > location for these records as certain remote devices get billed premium > rates for connect times. > > I've built a short term workaround where the sylogin.com will write a log > record with the information we require, and when we process the accounting > file we need to also process this other log file and match them up. > > How do I go about making a request to get the P1 space fields created for > this process, or can we run a program in sylogin.com that will populate them > for us ? > > Derek... > > > -----Original Message----- > > From: volz@process.com [SMTP:volz@process.com] > > Sent: 22 April 1999 18:41 > > To: Info-TCPware@PROCESS.COM > > Subject: Re: Telnet user accounting info > > > > In article <49B21CD935D0D011B4980000F875254F01753604@RDPEXC01>, Derek Fage > > writes: > > > Hi there, > > > > > > Does anybody know how to get TCPware to populate the remote node addr, > > > remote node name and remote ID in the accounting record for telnet > > > interactive connections ? It used to work with UCX, but not with Telnet, > > and > > > we need this information for billing / accounting purposes. > > > > > > > This is something that we've been meaning to add but haven't (basically > > the P1 space fields for these locations need to be filled in in the > > created process). > > > > If you change the configuration such that TELNET sessions are treated as > > local, instead of remote, you can sometimes get more information (in > > OPCOM messages, etc) as the "access port" information is included. See > > TELNET_CONTROL.COM. > > > > You can, of course, pull information out of NETCP.LOG. But that is more > > complex. > > > > - Bernie Volz > > Process Software > *********************************************************************** > 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 > 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 to administrator@itexjsy.com. > *********************************************************************** ================================================================================ Archive-Date: Thu, 22 Apr 1999 14:32:52 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753611@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Telnet user accounting info Date: Thu, 22 Apr 1999 19:26:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Barry, The problem is that we will still need to modify our MIS systems to do some extra work, as we need all of the connection time and exit status stuff that is in the accounting record when they log out. Derek... > -----Original Message----- > From: Barry Treahy [SMTP:treahy@mmaz.com] > Sent: 22 April 1999 19:19 > To: Info-TCPware@process.com > Subject: Re: Telnet user accounting info > > Derek,why don't you write a brief program using $SNDJBCW when they log in > to > record the related data into the accountng.dat file in a user defined > record? > This is what I had to do to capture login sources that were not typically > supported by the VMS accounting system... > > Barry > > Derek Fage wrote: > > > Hmmm. > > > > We've built a billing / MIS system around processing the accounting > records > > to populate our billing / stats databases. We need to know the remote > > location for these records as certain remote devices get billed premium > > rates for connect times. > > > > I've built a short term workaround where the sylogin.com will write a > log > > record with the information we require, and when we process the > accounting > > file we need to also process this other log file and match them up. > > > > How do I go about making a request to get the P1 space fields created > for > > this process, or can we run a program in sylogin.com that will populate > them > > for us ? > > > > Derek... > > > > > -----Original Message----- > > > From: volz@process.com [SMTP:volz@process.com] > > > Sent: 22 April 1999 18:41 > > > To: Info-TCPware@PROCESS.COM > > > Subject: Re: Telnet user accounting info > > > > > > In article <49B21CD935D0D011B4980000F875254F01753604@RDPEXC01>, Derek > Fage > > > writes: > > > > Hi there, > > > > > > > > Does anybody know how to get TCPware to populate the remote node > addr, > > > > remote node name and remote ID in the accounting record for telnet > > > > interactive connections ? It used to work with UCX, but not with > Telnet, > > > and > > > > we need this information for billing / accounting purposes. > > > > > > > > > > This is something that we've been meaning to add but haven't > (basically > > > the P1 space fields for these locations need to be filled in in the > > > created process). > > > > > > If you change the configuration such that TELNET sessions are treated > as > > > local, instead of remote, you can sometimes get more information (in > > > OPCOM messages, etc) as the "access port" information is included. See > > > TELNET_CONTROL.COM. > > > > > > You can, of course, pull information out of NETCP.LOG. But that is > more > > > complex. > > > > > > - Bernie Volz > > > Process Software > > *********************************************************************** > > 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 > > 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 to administrator@itexjsy.com. > > *********************************************************************** > > *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Thu, 22 Apr 1999 15:08:53 -0400 Message-ID: <371F7444.10665F3B@mmaz.com> Date: Thu, 22 Apr 1999 12:11:00 -0700 From: Barry Treahy Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Telnet user accounting info References: <49B21CD935D0D011B4980000F875254F01753611@RDPEXC01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When scanning the accounting records, you could still 'snag' these login messages and create a cache keyed by PID so that when you encounter a logout (an interactive process termination) record, you lookup in the cache what the login details and you're there... The problem with logouts? You can't force someone to always execute a program or procedure. STOP/ID=0 is the simplest example of how to circumvent all logout procedures... Barry Derek Fage wrote: > Barry, > > The problem is that we will still need to modify our MIS systems to do some > extra work, as we need all of the connection time and exit status stuff that > is in the accounting record when they log out. > > Derek... > > > -----Original Message----- > > From: Barry Treahy [SMTP:treahy@mmaz.com] > > Sent: 22 April 1999 19:19 > > To: Info-TCPware@process.com > > Subject: Re: Telnet user accounting info > > > > Derek,why don't you write a brief program using $SNDJBCW when they log in > > to > > record the related data into the accountng.dat file in a user defined > > record? > > This is what I had to do to capture login sources that were not typically > > supported by the VMS accounting system... > > > > Barry > > > > Derek Fage wrote: > > > > > Hmmm. > > > > > > We've built a billing / MIS system around processing the accounting > > records > > > to populate our billing / stats databases. We need to know the remote > > > location for these records as certain remote devices get billed premium > > > rates for connect times. > > > > > > I've built a short term workaround where the sylogin.com will write a > > log > > > record with the information we require, and when we process the > > accounting > > > file we need to also process this other log file and match them up. > > > > > > How do I go about making a request to get the P1 space fields created > > for > > > this process, or can we run a program in sylogin.com that will populate > > them > > > for us ? > > > > > > Derek... > > > > > > > -----Original Message----- > > > > From: volz@process.com [SMTP:volz@process.com] > > > > Sent: 22 April 1999 18:41 > > > > To: Info-TCPware@PROCESS.COM > > > > Subject: Re: Telnet user accounting info > > > > > > > > In article <49B21CD935D0D011B4980000F875254F01753604@RDPEXC01>, Derek > > Fage > > > > writes: > > > > > Hi there, > > > > > > > > > > Does anybody know how to get TCPware to populate the remote node > > addr, > > > > > remote node name and remote ID in the accounting record for telnet > > > > > interactive connections ? It used to work with UCX, but not with > > Telnet, > > > > and > > > > > we need this information for billing / accounting purposes. > > > > > > > > > > > > > This is something that we've been meaning to add but haven't > > (basically > > > > the P1 space fields for these locations need to be filled in in the > > > > created process). > > > > > > > > If you change the configuration such that TELNET sessions are treated > > as > > > > local, instead of remote, you can sometimes get more information (in > > > > OPCOM messages, etc) as the "access port" information is included. See > > > > TELNET_CONTROL.COM. > > > > > > > > You can, of course, pull information out of NETCP.LOG. But that is > > more > > > > complex. > > > > > > > > - Bernie Volz > > > > Process Software > > > *********************************************************************** > > > 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 > > > 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 to administrator@itexjsy.com. > > > *********************************************************************** > > > > > *********************************************************************** > 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 > 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 to administrator@itexjsy.com. > *********************************************************************** ================================================================================ Archive-Date: Thu, 22 Apr 1999 15:51:15 -0400 Subject: RE: Telnet user accounting info Message-ID: <1999Apr22.152317@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 22 Apr 99 15:23:17 -0500 To: Info-TCPware@PROCESS.COM In article <49B21CD935D0D011B4980000F875254F0175360F@RDPEXC01>, Derek Fage writes: > Hmmm. > > ... > How do I go about making a request to get the P1 space fields created for > this process, or can we run a program in sylogin.com that will populate them > for us ? > > Derek... > This is best requested via our technical support department. They can file the necessary request (D/E - E for enhancement). - Bernie Volz ================================================================================ Archive-Date: Thu, 22 Apr 1999 15:51:18 -0400 Subject: Re: FTP problems Message-ID: <1999Apr22.152111@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 22 Apr 99 15:21:11 -0500 To: Info-TCPware@PROCESS.COM In article <1999Apr22.122818@alcor.process.com>, volz@process.com (Bernie Volz) writes: > In article <371ee9ee.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >> In article <49B21CD935D0D011B4980000F875254F017535DD@RDPEXC01>, Derek Fage writes: >>>We have had a strange problem since installing TCPware over the weekend when >>>we FTP a file to a remote unix system >> >> We have a lot more FTP aborts with TCPware than with UCX. Still don't know >> why (maybe timeout value is smaller than in UCX), but didn't do many tests, >> so far. So no complaint/service call... >> > Another thought ... perhaps Path MTU is the problem. The DF bit would be set on all packets and perhaps this causes a problem in some cases and the problem system doesn't handle sending ICMP errors properly? UCX (pre 5.0 I believe) don't support Path MTU. - Bernie ================================================================================ Archive-Date: Fri, 23 Apr 1999 05:32:21 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E02BB@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: Telnet authentification Date: Fri, 23 Apr 1999 11:01:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 From a system A, I want to have a telnet session on a remote system B. System B is on a Y2K network. B is DNS client. The DNS server is system = C on Y2K lan. The problem is that B requests reverse dns about A ip address but C = doesn't kown A. So B still tries dns requests during 1 minute and after the telnet = session from A is OK. Is there a logical for telnet to suppress source authentification? Regards, Pierre Clairembault ----------------------------- Banque CPR Architecture/r=E9seau e-mail : pclairembault@cpr.fr tel : 01 45 96 23 49 Fax : 01 45 96 29 77 ================================================================================ Archive-Date: Fri, 23 Apr 1999 05:42:15 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753619@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Telnet authentification Date: Fri, 23 Apr 1999 10:43:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pierre, For Telnet, look at the TCPWARE_TELNETD_FLAGS logical described in the Management Guide (Chapter 17 - Managing TELNET-OpenVMS Server). Another options if the client is using a private address is to modify = the DNS server to make it authorative for the private addresses you use internally. This is what we did to get around the problem, as other utilities may also try reverse DNS lookups and suffer from timeouts. Derek... > -----Original Message----- > From: CLAIREMBAULT Pierre [SMTP:PCLAIREMBAULT@CPR.FR] > Sent: 23 April 1999 10:02 > To: Info-TCPware@process.com > Subject: Telnet authentification >=20 > Hello,=20 >=20 > From a system A, I want to have a telnet session on a remote system = B. >=20 > System B is on a Y2K network. B is DNS client. The DNS server is = system C > on > Y2K lan. >=20 > The problem is that B requests reverse dns about A ip address but C > doesn't > kown A. > So B still tries dns requests during 1 minute and after the telnet = session > from A is OK. >=20 > Is there a logical for telnet to suppress source authentification? >=20 > Regards, >=20 > Pierre Clairembault > ----------------------------- > Banque CPR > Architecture/r=E9seau > e-mail : pclairembault@cpr.fr > tel : 01 45 96 23 49 > Fax : 01 45 96 29 77 *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 23 Apr 1999 05:55:16 -0400 Date: Fri, 23 Apr 1999 10:54:23 +0100 From: "Raymond, David" Reply-To: Info-TCPware@process.com Subject: RE: Telnet authentification To: "'Info-TCPware@process.com'" Message-ID: <90088CB087DBD21194870008C733B45D048BF9@NTESS005> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: QUOTED-PRINTABLE Pierre, Note - A timeout usually indicates a problem with the DNS configurati= on. =20 If the problem was simply that the address of A was unknown, then the= DNS on B should return the information that the address was unknown promptly= - certainly far quicker than a minute. I regard using TCPWARE_TELNETD_FLAGS as a stop-gap solution whilst DN= S is sorted out. Regards David >-----Original Message----- >From: Derek Fage [mailto:Derekf@ITEXJSY.com] >Sent: 23 April 1999 10:43 >To: 'Info-TCPware@process.com' >Subject: RE: Telnet authentification > > >Pierre, > >For Telnet, look at the TCPWARE_TELNETD_FLAGS logical described in t= he >Management Guide (Chapter 17 - Managing TELNET-OpenVMS Server). > >Another options if the client is using a private address is to=20 >modify the >DNS server to make it authorative for the private addresses you use >internally. This is what we did to get around the problem, as other >utilities may also try reverse DNS lookups and suffer from timeouts. > >Derek... > > > >> -----Original Message----- >> From:=09CLAIREMBAULT Pierre [SMTP:PCLAIREMBAULT@CPR.FR] >> Sent:=0923 April 1999 10:02 >> To:=09Info-TCPware@process.com >> Subject:=09Telnet authentification >>=20 >> Hello,=20 >>=20 >> From a system A, I want to have a telnet session on a remote=20 >system B. >>=20 >> System B is on a Y2K network. B is DNS client. The DNS=20 >server is system C >> on >> Y2K lan. >>=20 >> The problem is that B requests reverse dns about A ip address but = C >> doesn't >> kown A. >> So B still tries dns requests during 1 minute and after the=20 >telnet session >> from A is OK. >>=20 >> Is there a logical for telnet to suppress source authentification? >>=20 >> Regards, >>=20 >> Pierre Clairembault >> ----------------------------- >> Banque CPR >> Architecture/r=E9seau >> e-mail : pclairembault@cpr.fr >> tel : 01 45 96 23 49 >> Fax : 01 45 96 29 77 >********************************************************************= *** >Any views expressed in this message are those of the individual send= er, >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 >dissemination, distribution or copying is strictly prohibited. If yo= u >have received this message in error please delete it immediately and >advise us by return e-mail to administrator@itexjsy.com. >********************************************************************= *** > ================================================================================ Archive-Date: Fri, 23 Apr 1999 06:12:20 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0175361C@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Telnet authentification Date: Fri, 23 Apr 1999 11:06:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yup - but there will be timeouts when you come from a private address = if the DNS server is configured as a caching server as it tries to get info = back from the root servers (we certainly had big problems yesterday with = this - interestingly there had not been any problems before then, so it could = be an internet type issue). I still feel that if your DNS server is an internal server configured = for caching, it may be worth making it authorative for private ip address subnets that you use internally (you could also then start actually resolving the private addresses to names if required). Any DNS experts with any comments on this ? Derek... > -----Original Message----- > From: Raymond, David [SMTP:david.raymond@essential.co.uk] > Sent: 23 April 1999 10:54 > To: 'Info-TCPware@process.com' > Subject: RE: Telnet authentification >=20 > Pierre, >=20 > Note - A timeout usually indicates a problem with the DNS = configuration. =20 >=20 > If the problem was simply that the address of A was unknown, then the = DNS > on > B should return the information that the address was unknown promptly = - > certainly far quicker than a minute. >=20 > I regard using TCPWARE_TELNETD_FLAGS as a stop-gap solution whilst = DNS is > sorted out. >=20 > Regards >=20 > David >=20 > >-----Original Message----- > >From: Derek Fage [mailto:Derekf@ITEXJSY.com] > >Sent: 23 April 1999 10:43 > >To: 'Info-TCPware@process.com' > >Subject: RE: Telnet authentification > > > > > >Pierre, > > > >For Telnet, look at the TCPWARE_TELNETD_FLAGS logical described in = the > >Management Guide (Chapter 17 - Managing TELNET-OpenVMS Server). > > > >Another options if the client is using a private address is to=20 > >modify the > >DNS server to make it authorative for the private addresses you use > >internally. This is what we did to get around the problem, as other > >utilities may also try reverse DNS lookups and suffer from timeouts. > > > >Derek... > > > > > > > >> -----Original Message----- > >> From: CLAIREMBAULT Pierre [SMTP:PCLAIREMBAULT@CPR.FR] > >> Sent: 23 April 1999 10:02 > >> To: Info-TCPware@process.com > >> Subject: Telnet authentification > >>=20 > >> Hello,=20 > >>=20 > >> From a system A, I want to have a telnet session on a remote=20 > >system B. > >>=20 > >> System B is on a Y2K network. B is DNS client. The DNS=20 > >server is system C > >> on > >> Y2K lan. > >>=20 > >> The problem is that B requests reverse dns about A ip address but = C > >> doesn't > >> kown A. > >> So B still tries dns requests during 1 minute and after the=20 > >telnet session > >> from A is OK. > >>=20 > >> Is there a logical for telnet to suppress source authentification? > >>=20 > >> Regards, > >>=20 > >> Pierre Clairembault > >> ----------------------------- > >> Banque CPR > >> Architecture/r=E9seau > >> e-mail : pclairembault@cpr.fr > >> tel : 01 45 96 23 49 > >> Fax : 01 45 96 29 77 > = >***********************************************************************= > >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 > >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 to administrator@itexjsy.com. > = >***********************************************************************= > > *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 23 Apr 1999 06:25:46 -0400 Date: Fri, 23 Apr 1999 11:22:41 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: Re: Telnet authentification In-Reply-To: <5BF932D2CD05D211B54800805FE60FEB029E02BB@serv-hermes.systeme.cpr.fr> To: CLAIREMBAULT Pierre , Info-TCPware Message-ID: <99Apr23.112412bst.14384@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN Pierre, Try adding the following to your TCPWARE:TCPWARE_CONFIGURE.COM file. TELNETD_FLAGS == 257 /Steve ================================================================================ Archive-Date: Fri, 23 Apr 1999 08:43:00 -0400 Sender: schreiber@process.com Date: Fri, 23 Apr 1999 08:42:57 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D70ED.C01A6569.103@process.com> Subject: RE: Telnet authentification Derek Fage writes: > >I still feel that if your DNS server is an internal server configured for >caching, it may be worth making it authorative for private ip address >subnets that you use internally (you could also then start actually >resolving the private addresses to names if required). > >Any DNS experts with any comments on this ? > Pure and simple... if private address lookups are getting out to the root servers, you've done something wrong. If you have an internal network, you need to block resolution of those internal addresses from getting outside the internal network. If you have all caching servers, make one a primary for the internal addresses. Have all others either secondary, or stub, or forward-only to that one that is authoritative. You in fact don't even need to manage them. As long as the private address in-addr zone exists, and has an SOA and NS record in it, you will get NXDOMAIN responses to any PTR queries in that zone... which is fine because that response is quick, and you don't have to wait until they time out. >(we certainly had big problems yesterday with this - >interestingly there had not been any problems before then, so it could be an >internet type issue). There was recently a change in the root servers where they respond authoritatively with the name of "read-rfc1918-for-details.iana.net". While that was being done, you probably wouldn't have seen any delays. They changed it back to the root servers being bit-buckets for the private addresses... so it's going to time out because it doesn't get a response. So the moral of the story is... If you can get to it from a private network, then it's in the private network, and needs to be able to resolve the private network. That includes both forward (A records) _AND_ reverse (PTR records). - Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 23 Apr 1999 09:22:01 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0175361F@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Telnet authentification Date: Fri, 23 Apr 1999 14:21:54 +0100 MIME-Version: 1.0 Content-Type: text/plain Ah, That explains it ! I did have some instances in out log files of hosts that resolved to read-rfc1918-for-details.iana.net for a couple of days, and then we had all of the timeout isses (we only setup the DNS servers to cache out to the internet at the weekend). We got around it in exactly the way you explained (making the primary authorative for the internal addresses). This only really came about due to the fact that the DNS server is a private internal DNS server that is dual-homed and caches out to the internet. I'd also seen the read-rfc1918-for-details.iana.net in some FireWall log files and wondered what it was - now I know 8-) Thanks for the info, Derek... > -----Original Message----- > From: Jeff Schreiber [SMTP:schreiber@process.com] > Sent: 23 April 1999 13:43 > To: Info-TCPware@process.com > Cc: schreiber@process.com > Subject: RE: Telnet authentification > > Derek Fage writes: > > > >I still feel that if your DNS server is an internal server configured for > >caching, it may be worth making it authorative for private ip address > >subnets that you use internally (you could also then start actually > >resolving the private addresses to names if required). > > > >Any DNS experts with any comments on this ? > > > > Pure and simple... if private address lookups are getting out to the > root servers, you've done something wrong. > > If you have an internal network, you need to block resolution of those > internal addresses from getting outside the internal network. > > If you have all caching servers, make one a primary for the internal > addresses. Have all others either secondary, or stub, or forward-only > to that one that is authoritative. > > You in fact don't even need to manage them. As long as the private > address in-addr zone exists, and has an SOA and NS record in it, you > will get NXDOMAIN responses to any PTR queries in that zone... which > is fine because that response is quick, and you don't have to wait > until > they time out. > > >(we certainly had big problems yesterday with this - > >interestingly there had not been any problems before then, so it could be > an > >internet type issue). > > There was recently a change in the root servers where they respond > authoritatively with the name of "read-rfc1918-for-details.iana.net". > While that was being done, you probably wouldn't have seen any delays. > > They changed it back to the root servers being bit-buckets for the > private addresses... so it's going to time out because it doesn't get > a response. > > > So the moral of the story is... If you can get to it from a private > network, then it's in the private network, and needs to be able to > resolve the private network. That includes both forward (A records) > _AND_ reverse (PTR records). > > - Jeff > > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 23 Apr 1999 09:36:42 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E02BD@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Telnet authentification Date: Fri, 23 Apr 1999 15:36:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you very much everybody for your answers. In fact, I have = reconfigured telnetd_flags=3D=3D257. It works fine. Pierre -----Message d'origine----- De: CLAIREMBAULT Pierre [mailto:PCLAIREMBAULT@CPR.FR] Date: vendredi 23 avril 1999 11:02 =C0: Info-TCPware@process.com Objet: Telnet authentification Hello,=20 From a system A, I want to have a telnet session on a remote system B. System B is on a Y2K network. B is DNS client. The DNS server is system = C on Y2K lan. The problem is that B requests reverse dns about A ip address but C = doesn't kown A. So B still tries dns requests during 1 minute and after the telnet = session from A is OK. Is there a logical for telnet to suppress source authentification? Regards, Pierre Clairembault ----------------------------- Banque CPR Architecture/r=E9seau e-mail : pclairembault@cpr.fr tel : 01 45 96 23 49 Fax : 01 45 96 29 77 ================================================================================ Archive-Date: Fri, 23 Apr 1999 13:13:30 -0400 From: cousera@my-dejanews.com Reply-To: Info-TCPware@process.com Subject: TCPWARE FTP download problem Date: Fri, 23 Apr 1999 16:02:59 GMT Message-ID: <7fq5jg$2k3$1@nnrp1.dejanews.com> To: Info-TCPware@PROCESS.COM To All: We have a problem that has Process Software personnel as well as my in-house personnel stumped. If anyone out there has seen or heard of a similar problem, please let me know or if you have any suggestions. We are using Process Software TCPware product in-house for our TCP/IP communication. We are in the process of migrating from a VAX 4700 running OpenVMS 6.2 and TCPware 5.2 to an Alphaserver 4100 running OpenVMS/AXP 7.1-1h2 and TCPware 5.3-3. The TCP/IP environmental settings have been duplicated between the two system. We have two downloads jobs that FTP 'GET' a file from an IBM mainframe system every day. These two FTPs work fine on the VAX, however, the same process fails on the Alphaserver. We have also tried from a duplicate Alphaserver at another location and GET'ing other files with the same results. 'GET' works to other systems from the Alpha just not the IBM mainframe.With the same systems 'PUT' works fine, but 'GET' on any type of file fails. Here is the script and results we are getting: $ FTP OPEN XXX USERID password 220-TCPFTP1 IBM MVS V3R2 at SYSTEM.CORP.XXXX.COM, 15:49:06 on 1999/01/11 220 Connection will close if idle for more than 5 minutes. 331 Send password please. 230 USERID is logged on. Working directory is "USERID.". 200-Unrecognized option '+VMS+' on site command. 200 Site command was accepted ERROR_EXIT %X10000010 QUOTE CWD 'dir.name.seq' 250 "'dir.name.seq.'" is working directory name prefix ERROR_EXIT %X10000010 QUOTE SITE TRAILING 200 Site command was accepted ERROR_EXIT %X10000010 GET/LOG FILE001 FILE001.DAT 200 Port request OK. 125 Sending data set dir.name.seq.FILE001 FIXrecfm 40 250 Transfer completed successfully. %TCPWARE_FTP-E-FILWRTERR, error writing to or receiving SYS$SYSDEVICE:[SYS0.SITE. BATCH.FILES]FILE001.DAT;1 -SYSTEM-F-VCBROKEN, virtual circuit broken ERROR_EXIT %X10000010 221 Quit command received. Goodbye. We have checked a NETCU DEBUG of the process and found that although a file is created, no data is transferred and the maniframe responds that the transfer is complete. Any assistance would be greatly appreciated. Thanks -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ================================================================================ Archive-Date: Fri, 23 Apr 1999 13:48:10 -0400 Message-ID: <3720B254.E0CF0DD6@process.com> Date: Fri, 23 Apr 1999 13:48:04 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: TCPWARE FTP download problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > To All: > > We have a problem that has Process Software personnel as well as my in-house > personnel stumped. If anyone out there has seen or heard of a similar > problem, please let me know or if you have any suggestions. > > We are using Process Software TCPware product in-house for our TCP/IP > communication. We are in the process of migrating from a VAX 4700 > running OpenVMS 6.2 and TCPware 5.2 to an Alphaserver 4100 running > OpenVMS/AXP 7.1-1h2 and TCPware 5.3-3. The TCP/IP environmental > settings have been duplicated between the two system. We have two > downloads jobs that FTP 'GET' a file from an IBM mainframe system > every day. These two FTPs work fine on the VAX, however, the same > process fails on the Alphaserver. We have also tried from a duplicate > Alphaserver at another location and GET'ing other files with the same > results. 'GET' works to other systems from the Alpha just not the IBM > mainframe.With the same systems 'PUT' works fine, but 'GET' on any > type of file fails. > > Here is the script and results we are getting: > > $ FTP > OPEN XXX USERID password > 220-TCPFTP1 IBM MVS V3R2 at SYSTEM.CORP.XXXX.COM, 15:49:06 on > 1999/01/11 > 220 Connection will close if idle for more than 5 minutes. > 331 Send password please. > 230 USERID is logged on. Working directory is "USERID.". > 200-Unrecognized option '+VMS+' on site command. > 200 Site command was accepted > ERROR_EXIT %X10000010 > QUOTE CWD 'dir.name.seq' > 250 "'dir.name.seq.'" is working directory name prefix > ERROR_EXIT %X10000010 > QUOTE SITE TRAILING > 200 Site command was accepted > > > ERROR_EXIT %X10000010 > GET/LOG FILE001 FILE001.DAT > 200 Port request OK. > 125 Sending data set dir.name.seq.FILE001 FIXrecfm 40 > 250 Transfer completed successfully. > %TCPWARE_FTP-E-FILWRTERR, error writing to or receiving > SYS$SYSDEVICE:[SYS0.SITE. > BATCH.FILES]FILE001.DAT;1 > -SYSTEM-F-VCBROKEN, virtual circuit broken > ERROR_EXIT %X10000010 > 221 Quit command received. Goodbye. > > We have checked a NETCU DEBUG of the process and found that although a file > is created, no data is transferred and the maniframe responds that the > transfer is complete. Any assistance would be greatly appreciated. My first guess would be that the problem is that TCPware's FTP client thinks its in VMSPLUS mode because the server replied to the SITE +VMSPLUS+ with - 200-Unrecognized option '+VMS+' on site command. It used a 200 return code indicating success but the text shows that it was not successful. Try issuing the DISABLE VMS command after the login and before the transfer is attempted. 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: Fri, 23 Apr 1999 16:42:12 -0400 From: cousera@my-dejanews.com Reply-To: Info-TCPware@process.com Subject: RE: TCPWARE FTP download problem Date: Fri, 23 Apr 1999 20:26:50 GMT Message-ID: <7fql25$hgp$1@nnrp1.dejanews.com> To: Info-TCPware@PROCESS.COM In article <3720B254.E0CF0DD6@process.com>, Michael Corbett wrote: > > To All: > > > > We have a problem that has Process Software personnel as well as my in-house > > personnel stumped. If anyone out there has seen or heard of a similar > > problem, please let me know or if you have any suggestions. > > > > We are using Process Software TCPware product in-house for our TCP/IP > > communication. We are in the process of migrating from a VAX 4700 > > running OpenVMS 6.2 and TCPware 5.2 to an Alphaserver 4100 running > > OpenVMS/AXP 7.1-1h2 and TCPware 5.3-3. The TCP/IP environmental > > settings have been duplicated between the two system. We have two > > downloads jobs that FTP 'GET' a file from an IBM mainframe system > > every day. These two FTPs work fine on the VAX, however, the same > > process fails on the Alphaserver. We have also tried from a duplicate > > Alphaserver at another location and GET'ing other files with the same > > results. 'GET' works to other systems from the Alpha just not the IBM > > mainframe.With the same systems 'PUT' works fine, but 'GET' on any > > type of file fails. > > > > Here is the script and results we are getting: > > > > $ FTP > > OPEN XXX USERID password > > 220-TCPFTP1 IBM MVS V3R2 at SYSTEM.CORP.XXXX.COM, 15:49:06 on > > 1999/01/11 > > 220 Connection will close if idle for more than 5 minutes. > > 331 Send password please. > > 230 USERID is logged on. Working directory is "USERID.". > > 200-Unrecognized option '+VMS+' on site command. > > 200 Site command was accepted > > ERROR_EXIT %X10000010 > > QUOTE CWD 'dir.name.seq' > > 250 "'dir.name.seq.'" is working directory name prefix > > ERROR_EXIT %X10000010 > > QUOTE SITE TRAILING > > 200 Site command was accepted > > > > > > ERROR_EXIT %X10000010 > > GET/LOG FILE001 FILE001.DAT > > 200 Port request OK. > > 125 Sending data set dir.name.seq.FILE001 FIXrecfm 40 > > 250 Transfer completed successfully. > > %TCPWARE_FTP-E-FILWRTERR, error writing to or receiving > > SYS$SYSDEVICE:[SYS0.SITE. > > BATCH.FILES]FILE001.DAT;1 > > -SYSTEM-F-VCBROKEN, virtual circuit broken > > ERROR_EXIT %X10000010 > > 221 Quit command received. Goodbye. > > > > We have checked a NETCU DEBUG of the process and found that although a file > > is created, no data is transferred and the maniframe responds that the > > transfer is complete. Any assistance would be greatly appreciated. > > My first guess would be that the problem is that TCPware's FTP > client thinks its in VMSPLUS mode because the server replied to the > SITE +VMSPLUS+ with - > > 200-Unrecognized option '+VMS+' on site command. > > It used a 200 return code indicating success but the text shows > that it was not successful. Try issuing the DISABLE VMS > command after the login and before the transfer is attempted. > > 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 > Michael, We've tried that with no results. Alan -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ================================================================================ Archive-Date: Sat, 24 Apr 1999 18:40:34 -0400 From: "Brian Steele" Reply-To: Info-TCPware@process.com Subject: LPR Printing problems with TCPWare Date: Fri, 23 Apr 1999 08:53:23 -0400 Message-ID: <7fpqjp$8631@col3.caribsurf.com> To: Info-TCPware@PROCESS.COM Hi Everyone: I've set up a few queues on my VAX that point to a number of queues running on NT box acting as a printserver. The transport used is TCP/IP, and I'm running TCPWare on the VAX under VMS 7.1 For the most part the queues run correctly. However, one particular print job is generating the following error on the VAX - any ideas on what's causing the error and what I could do to sort it out? --- %TCPWARE_LPR-F-TRANSFER, fatal error occured with network transfer - TCPWARE_LPR-I-JOB_ID, for job 9904_302C_990422_TP_SWV_9903_00 (queue [queue_name], entry [entry_name], on [queue_name] - SYSTEM-F-IVBUFLEN, invalid buffer length --- Regards, Brian Steele ================================================================================ Archive-Date: Sat, 24 Apr 1999 18:40:37 -0400 Subject: Re: TCPWARE FTP download problem Message-ID: <1999Apr23.181226@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 23 Apr 99 18:12:26 -0500 To: Info-TCPware@PROCESS.COM Try: OPEN/NOVMS instead of SET NOVMS. There is a difference. OPEN/NOVMS is really recommended as it doesn't even attempt the negotiation. - Bernie Volz Process Software In article <7fq5jg$2k3$1@nnrp1.dejanews.com>, cousera@my-dejanews.com writes: > To All: > > We have a problem that has Process Software personnel as well as my in-house > personnel stumped. If anyone out there has seen or heard of a similar > problem, please let me know or if you have any suggestions. > > We are using Process Software TCPware product in-house for our TCP/IP > communication. We are in the process of migrating from a VAX 4700 > running OpenVMS 6.2 and TCPware 5.2 to an Alphaserver 4100 running > OpenVMS/AXP 7.1-1h2 and TCPware 5.3-3. The TCP/IP environmental > settings have been duplicated between the two system. We have two > downloads jobs that FTP 'GET' a file from an IBM mainframe system > every day. These two FTPs work fine on the VAX, however, the same > process fails on the Alphaserver. We have also tried from a duplicate > Alphaserver at another location and GET'ing other files with the same > results. 'GET' works to other systems from the Alpha just not the IBM > mainframe.With the same systems 'PUT' works fine, but 'GET' on any > type of file fails. > > Here is the script and results we are getting: > > $ FTP > OPEN XXX USERID password > 220-TCPFTP1 IBM MVS V3R2 at SYSTEM.CORP.XXXX.COM, 15:49:06 on > 1999/01/11 > 220 Connection will close if idle for more than 5 minutes. > 331 Send password please. > 230 USERID is logged on. Working directory is "USERID.". > 200-Unrecognized option '+VMS+' on site command. > 200 Site command was accepted > ERROR_EXIT %X10000010 > QUOTE CWD 'dir.name.seq' > 250 "'dir.name.seq.'" is working directory name prefix > ERROR_EXIT %X10000010 > QUOTE SITE TRAILING > 200 Site command was accepted > > > ERROR_EXIT %X10000010 > GET/LOG FILE001 FILE001.DAT > 200 Port request OK. > 125 Sending data set dir.name.seq.FILE001 FIXrecfm 40 > 250 Transfer completed successfully. > %TCPWARE_FTP-E-FILWRTERR, error writing to or receiving > SYS$SYSDEVICE:[SYS0.SITE. > BATCH.FILES]FILE001.DAT;1 > -SYSTEM-F-VCBROKEN, virtual circuit broken > ERROR_EXIT %X10000010 > 221 Quit command received. Goodbye. > > We have checked a NETCU DEBUG of the process and found that although a file > is created, no data is transferred and the maniframe responds that the > transfer is complete. Any assistance would be greatly appreciated. > > Thanks > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ================================================================================ Archive-Date: Sun, 25 Apr 1999 13:42:28 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F01753632@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: FTP problems Date: Sun, 25 Apr 1999 18:37:53 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi there, Thanks for all the help everybody gave me on this issue - I thought I'd post a short reply to the newsgroup to let you the outcome this problem. It turns out that the problem was down to the fact that we had stac compression switched on on the serial interfaces of the Cisco routers between us and the client site. Turning off the compression appears to have resolved the problem. I'll now pass this information on to Cisco to see if they can identify any problems in the stac compression that would give us these symptoms. Thanks again, Derek... > -----Original Message----- > From: volz@process.com [SMTP:volz@process.com] > Sent: 22 April 1999 21:21 > To: Info-TCPware@PROCESS.COM > Subject: Re: FTP problems > > In article <1999Apr22.122818@alcor.process.com>, volz@process.com (Bernie > Volz) writes: > > In article <371ee9ee.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter > LANGSTOEGER) writes: > >> In article <49B21CD935D0D011B4980000F875254F017535DD@RDPEXC01>, Derek > Fage writes: > >>>We have had a strange problem since installing TCPware over the weekend > when > >>>we FTP a file to a remote unix system > >> > >> We have a lot more FTP aborts with TCPware than with UCX. Still don't > know > >> why (maybe timeout value is smaller than in UCX), but didn't do many > tests, > >> so far. So no complaint/service call... > >> > > > > Another thought ... perhaps Path MTU is the problem. The DF bit would > be set on all packets and perhaps this causes a problem in some cases > and the problem system doesn't handle sending ICMP errors properly? > > UCX (pre 5.0 I believe) don't support Path MTU. > > - Bernie *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Mon, 26 Apr 1999 11:37:51 -0400 Date: Mon, 26 Apr 1999 11:37:07 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTPD_PIP_V533P010 To: TCPware-Announce@PROCESS.COM Message-ID: <01JAHKE003S2001Y19@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: FTPD_PIP_V533P010 Description: TCPWARE_FTPD_NOUNIX_SYNTAX logical added Release date: 26-APR-1999 Versions: 5.3-3, 5.3-2 ftp://ftp.process.com/support/53_3/ftpd_pip_v533p010.zip To search the TCPware ECO database, please visit the following URL: http://www.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ----------------------------------------------------------------------- FTP Patch kit (revision 1.0) for TCPware version 5.3-2 24-Mar-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of FTPD_PIP.EXE for TCPware for OpenVMS. TCPWare V5.3-2 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made: The TCPWARE_FTPD_NOUNIX_SYNTAX logical can now also be used to cause the LIST (directory) command to not be parsed as if it was a Unix directory specification. This fixes a problem when DIR [dirname]/DATE is done from a foreign client. (DE 3399) [End of ECO announcement] ================================================================================ Archive-Date: Tue, 27 Apr 1999 12:30:46 -0400 From: melancon@pubsys.com (Mike M.) Subject: DSNlink over tcpware Date: Tue, 27 Apr 1999 15:20:59 GMT Message-ID: <3726cf37.76362363@enews.newsguy.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 Has anyone ever managed to get DSNlink version 2.2 to work over TCPware? Compaq's stated position is that it's only supported over UCX, but the CSC guy said he knew that some users had managed to get it running over MultiNet. There are commands in the DSN$STARTUP file such as the following: $ ucx enable service dsn_its so I'm thinking of replacing them with: netcu> add service dsn_its 2373 bg_tcp /username=aes_dsnlink /input=sys$sysdevice:[dsn.com]dsn_its_server.com but I'd like to know if anyone has had success doing this. ================================================================================ Archive-Date: Tue, 27 Apr 1999 14:03:47 -0400 Message-ID: <3725FBF0.7DEADA86@wku.edu> Date: Tue, 27 Apr 1999 13:03:28 -0500 From: "Curtis Williams" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: DSNlink over tcpware References: <3726cf37.76362363@enews.newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Mike M." wrote: > Has anyone ever managed to get DSNlink version 2.2 to work over > TCPware? Yes, I have had it working for about a year. This may not be everything (it's been a while, I really don't remember clearly), but I here's what I have done: In TCPWARE:SERVICES.: Add these lines (I put mine at the bottom): dsn_nsd 2370/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 In SYS$STARTUP:DSN$STARTUP.COM: around line 467 I have put in the following code: $! $! Enable the UCX Services, since we don't check $! to see if they still exist. $! $ if do_tcpip $ then $ if f$trnlnm("tcpware") .nes. "" $ then $! $ else $ define sys$output nla0: $ define sys$error nla0: $ ucx enable service dsn_nsd $ ucx enable service dsn_mail $ ucx enable service dsn_its $ ucx enable service dsn_k2 $ ucx enable service dsn_login $ ucx enable service dsn_netex $ ucx enable service dsn_sra $ ucx enable service dsn_file $ deassign sys$output $ deassign sys$error $ endif $ endif around line 1204 I have put in the following code: $ if user .eqs. "" then user = "AES_DSNLINK" $ file = "DSN$COMMAND:" + f$parse(p4,"''name'_server",,"name","syntax_only") ` $ flags = "(Listen,Multithreaded,Noproxy)" $ logfile = "DSN$LOGS:" + f$parse(file,,,"name","syntax_only") + ".LOG" $ proc = f$extract(0,15,name) $ if f$trnlnm("tcpware") .nes. "" $ then $ netcu == "$tcpware:netcu" $ netcu add service 'name' BG_TCP - /input = 'file' - /username = 'user' - /log $ else $ ! Remove the service first $ call Remove_UCX_Service 'name' $ ! Setup the service $ ucx set service 'name' - /port = 'port' - /file = 'file' - /user = 'user' - /proc = "''proc'" - /flags = 'flags' - /limit = 32767 - /log = (all,file="''logfile'") $ ! Enable the service $ ucx enable service 'name' $ endif $ ! done -- | ____/ | /| / 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: Tue, 27 Apr 1999 15:38:52 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: DSNlink over tcpware Date: 27 Apr 1999 21:07:14 +0100 Message-ID: <37260ae2.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <3726cf37.76362363@enews.newsguy.com>, melancon@pubsys.com (Mike M.) writes: >Has anyone ever managed to get DSNlink version 2.2 to work over >TCPware? Compaq's stated position is that it's only supported over >UCX, but the CSC guy said he knew that some users had managed to get >it running over MultiNet. > >There are commands in the DSN$STARTUP file such as the following: > >$ ucx enable service dsn_its > >so I'm thinking of replacing them with: > >netcu> add service dsn_its 2373 bg_tcp /username=aes_dsnlink >/input=sys$sysdevice:[dsn.com]dsn_its_server.com > >but I'd like to know if anyone has had success doing this. I'm currenly in the process to do it. Though, very low priority... So far, I managed to get ITS connection. Not more. Maybe it's a firewall problem. It is definitely a problem of my time... 1) We got DSNlink V2.2C from our DECrep. The V2.2C kit recently announced is different (in size). I'd like to know the differences, but our DECrep told me, V2.3 is "coming real soon now, so don't waste your time". 2) We fixed the bugs mentioned in two or three DSIN database articles.. eg. in DSN_CONFIG.DAT FileServer.Root.Path: dsn$incoming_files:,dsn$outgoing_files: But check the DSIN articles yourself, my memory is flakey... 3) We defined port numbers in TCPWARE:SERVICES. dsn_nsd 2370/tcp # DSNlink dsn_copy 2371/tcp # DSNlink dsn_mail 2372/tcp # DSNlink dsn_its 2373/tcp # DSNlink dsn_login 2374/tcp # DSNlink dsn_netex 2375/tcp # DSNlink dsn_sra 2376/tcp # DSNlink dsn_k2 2377/tcp # DSNlink dsn_file 2379/tcp # DSNlink 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 And after we entered the correct auth info in DSNlink (and we checked the IP connection to our CSC (dsnlink.europe.digital.com) we got ITS connection. And there we sit/stand/wait-for-more-time... Maybe the problems raise from missing /USERNAME in ADD SERVICE. Who knows... HIH -Peter PS: And of course DSNLINK$STARTUP.COM produces a lot of UCX errors then: %DCL-W-ACTIMAGE, error activating image UCX$CFS_SHR -CLI-E-IMGNAME, image file $1$DUA1:[SYS0.SYSCOMMON.][SYSLIB]UCX$CFS_SHR.EXE;1 -SYSTEM-F-PROTINSTALL, protected images must be installed ------------------------------------------------------------------------ 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, 27 Apr 1999 22:42:02 -0400 Subject: Re: DSNlink over tcpware Message-ID: <1999Apr27.221126@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 27 Apr 99 22:11:26 -0500 To: Info-TCPware@PROCESS.COM 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. ================================================================================ Archive-Date: Wed, 28 Apr 1999 07:45:48 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: DSNlink over tcpware Date: 28 Apr 1999 13:40:45 +0100 Message-ID: <3726f3bd.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM 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... ------------------------------------------------------------------------ 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, 28 Apr 1999 10:12:53 -0400 Date: Wed, 28 Apr 1999 08:15:27 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: DSNlink over tcpware In-Reply-To: <3726f3bd.0@nevada.kapsch.co.at> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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/ _________________________________________________________________________ ================================================================================ Archive-Date: Wed, 28 Apr 1999 13:09:13 -0400 Message-ID: <3727412D.49F8AF9A@mmaz.com> Date: Wed, 28 Apr 1999 10:11:09 -0700 From: Barry Treahy Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: VMS 5.5-2 & TCPWARE V5.3-2 Content-Type: multipart/alternative; boundary="------------9B2F93E507DE6755326AE4F0" --------------9B2F93E507DE6755326AE4F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just noticed truncation of the REMOTE PORT INFO for SOME telnet sessions from remote users with a long FQDN. What is strange is that others with shorter FQDN, work even though the data displayed is longer than what is displayed on the failed example. Both examples are listed below... Is this fixed and if not, when, because this makes logging of access activity rather useless... Barry Ps. the lexical f$getdvi returns the same truncated data. V4100$ show term Terminal: _VTA1138: Device_Type: Unknown Owner: Barry Treahy Physical terminal: _NTA2: Username: TREAHY Remote Port Info: ve.ltd.uk Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape Hostsync TTsync Lowercase No Tab Wrap Scope No Remote Eightbit Broadcast No Readsync No Form Fulldup No Modem No Local_echo Autobaud Hangup Brdcstmbx No DMA Altypeahd Set_speed No Commsync Line Editing Insert editing No Fallback No Dialup No Secure server Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad ANSI_CRT No Regis No Block_mode Advanced_video No Edit_mode DEC_CRT No DEC_CRT2 No DEC_CRT3 No DEC_CRT4 VMS Style Input V4100$ V4100$ show term Terminal: _VTA1136: Device_Type: Unknown Owner: Barry Treahy Physical terminal: _NTA1: Username: TREAHY Remote Port Info: dell400.mmaz.com Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape Hostsync TTsync Lowercase No Tab Wrap Scope No Remote Eightbit Broadcast No Readsync No Form Fulldup No Modem No Local_echo Autobaud Hangup Brdcstmbx No DMA Altypeahd Set_speed No Commsync Line Editing Insert editing No Fallback No Dialup No Secure server Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad ANSI_CRT No Regis No Block_mode Advanced_video No Edit_mode DEC_CRT No DEC_CRT2 No DEC_CRT3 No DEC_CRT4 VMS Style Input --------------9B2F93E507DE6755326AE4F0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I just noticed truncation of the REMOTE PORT INFO for SOME telnet sessions from remote users with a long FQDN.  What is strange is that others with shorter FQDN, work even though the data displayed is longer than what is displayed on the failed example.  Both examples are listed below...

Is this fixed and if not, when, because this makes logging of access activity rather useless...

Barry

Ps. the lexical f$getdvi returns the same truncated data.

V4100$ show term
Terminal: _VTA1138:   Device_Type: Unknown       Owner: Barry Treahy
Physical terminal: _NTA2:                     Username: TREAHY
Remote Port Info: ve.ltd.uk
 
   Input:   9600      LFfill:  0      Width:  80      Parity: None
   Output:  9600      CRfill:  0      Page:   24
 
Terminal Characteristics:
   Interactive        Echo               Type_ahead         No Escape
   Hostsync           TTsync             Lowercase          No Tab
   Wrap               Scope              No Remote          Eightbit
   Broadcast          No Readsync        No Form            Fulldup
   No Modem           No Local_echo      Autobaud           Hangup
   Brdcstmbx          No DMA             Altypeahd          Set_speed
   No Commsync        Line Editing       Insert editing     No Fallback
   No Dialup          No Secure server   Disconnect         No Pasthru
   No Syspassword     No SIXEL Graphics  No Soft Characters No Printer Port
   Numeric Keypad     ANSI_CRT           No Regis           No Block_mode
   Advanced_video     No Edit_mode       DEC_CRT            No DEC_CRT2
   No DEC_CRT3        No DEC_CRT4        VMS Style Input
V4100$

V4100$ show term
Terminal: _VTA1136:   Device_Type: Unknown       Owner: Barry Treahy
Physical terminal: _NTA1:                     Username: TREAHY
Remote Port Info: dell400.mmaz.com
 
   Input:   9600      LFfill:  0      Width:  80      Parity: None
   Output:  9600      CRfill:  0      Page:   24
 
Terminal Characteristics:
   Interactive        Echo               Type_ahead         No Escape
   Hostsync           TTsync             Lowercase          No Tab
   Wrap               Scope              No Remote          Eightbit
   Broadcast          No Readsync        No Form            Fulldup
   No Modem           No Local_echo      Autobaud           Hangup
   Brdcstmbx          No DMA             Altypeahd          Set_speed
   No Commsync        Line Editing       Insert editing     No Fallback
   No Dialup          No Secure server   Disconnect         No Pasthru
   No Syspassword     No SIXEL Graphics  No Soft Characters No Printer Port
   Numeric Keypad     ANSI_CRT           No Regis           No Block_mode
   Advanced_video     No Edit_mode       DEC_CRT            No DEC_CRT2
   No DEC_CRT3        No DEC_CRT4        VMS Style Input
  --------------9B2F93E507DE6755326AE4F0-- ================================================================================ Archive-Date: Wed, 28 Apr 1999 13:29:19 -0400 Message-ID: <3727453D.B969EFCB@process.com> Date: Wed, 28 Apr 1999 13:28:29 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: VMS 5.5-2 & TCPWARE V5.3-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I just noticed truncation of the REMOTE PORT INFO for SOME telnet > sessions from remote users with a long FQDN. What is strange is > that others with shorter FQDN, work even though the data displayed > is longer than what is displayed on the failed example. Both > examples are listed below... > Is this fixed and if not, when, because this makes logging of access > activity rather useless... > Barry, This is addressed in the following patch - ftp://ftp.process.com/support/53_2/NETCP_V532P020.ZIP Here is the readme for the patch. ECO kit NETCP_V532P020 NETCP Patch kit revision 2.0 for TCPware version 5.3-2 22-JAN-1998 Copyright (c) 1998, by Process Software Corporation This VMSinstallable saveset provides new versions of NETCP.EXE for TCPware for OpenVMS. This patch is applicable to TCPware version 5.3-2 and all supported versions of OpenVMS. A fix for the following problem has been made: NETCP was starting one more server process than the limit on the service. This problem can affect DHCP in particular since many errors may result if there is more than one DHCP server. This kit also contains the following fix(es) from the previous patch: TCPware 5.3's enhancement to display ACCPORNAM with the remote port number fails in these circumstances: a) If the host name string is exactly 20 characters long, then a TELNET login from that host gets SS$_IVBUFLEN and the user can not log in (the connection is closed). b) If the host name string is greater than 20 characters long, then the first 20 characters are dropped when setting the ACCPORNAM (in Remote Port Info). This problem can be overcome by: a) Installing this patch. b) Configuring TCPware to report the internet address (old style ACCPORNAM string) instead of the reporting the host name. (See TELNET_CONTROL.COM for adding mask value 256 to TELNETD_FLAGS.) The old version of TCPWARE:NETCP.EXE will be renamed to TCPWARE:NETCP.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE:NETCP.EXE NOTE: You do not need to reboot but you must start or restart TCPware to enable this patch. -------------------------------------------------------------------------------- -- +-------------------------------------------------------------------------+ 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, 29 Apr 1999 15:23:57 -0400 Sender: bryant@process.com Date: Thu, 29 Apr 1999 15:23:36 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: TCPWARE-ANNOUNCE@PROCESS.COM CC: bryant@process.com Message-ID: <009D75DC.B71DDE34.28@process.com> Subject: Mistaken URL for TCPware patch kit database It has come to my attention that the program which generates the announcements of new patch kits for TCPware was providing the wrong URL for our Web based patch kit database. I have fixed the program. Note that the URL for locating TCPware patch kits is: http://vms.process.com/eco.html Please note that most of the available patch kits are in the database, but not all. New patch kits are added to the database as they are released. I apologize for the earlier error. ================================================================================ Archive-Date: Thu, 29 Apr 1999 16:24:57 -0400 From: Sylvain Plante Reply-To: Info-TCPware@process.com Subject: NFS problems Date: Thu, 29 Apr 1999 15:22:30 -0400 Message-ID: <3728B176.B94E8662@rncan.gc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi everybody, We have a strange problem with NFS client. We are using OpenVMS 6.2-1H3, with TCPware 5.3 Here's what I have when I'm doing the directory for the FIRST time: $ dir nfs11:[000000] 040I14.LST;1 0/0 [0,0] 040I15.LST;1 0/0 [0,0] 040I16.LST;1 0/0 [0,0] $ Here's what I get the second time. Just a few SECOND after the first DIRECTORY command : $ dir nfs11:[000000] 040I14.LST;1 57/57 7-NOV-1995 07:42:25.00 [PROD,BOSSE] 040I15.LST;1 47/47 7-NOV-1995 07:42:25.00 [PROD,BOSSE] 040I16.LST;1 48/48 7-NOV-1995 07:42:25.00 [PROD,BOSSE] $ Why is the first time I'm not receiving the right information. Here's how the NFS disk 11 is mounted: NFSMOUNT/SYSTEM/CACHE=(DIR=00:00)1,ATT=00:00:01)/TRANS=TCP ROBIN "/export/raid/bdtc" NFS11 BDTC Sylvain Plante splante@rncan.gc.ca ================================================================================ Archive-Date: Thu, 29 Apr 1999 16:57:23 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F0175369D@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NFS problems Date: Thu, 29 Apr 1999 21:58:55 +0100 MIME-Version: 1.0 Content-Type: text/plain I've been meaning to report a similar issue. OpenVMS Alpha 7.1-1H2, TCPware 5.3-3 NFS client to a some Solaris 2.5.1 UltraSparc systems. Our developers have told me that sometimes they need to do a directory twice before they see the latest files (even though the files were created on the unix system 5-10 mins prior to rhe first time they did a directory). This is one of those things on my "I'll get around to looking into" list that was not impacting production (due to programs that are looking for these files doing a directory lookup every 30 seconds when they expect to find a file). I have tried changing all sorts of different cache settings on the NFSMOUNT command but to no avail. Any hints / tips / tricks appreciated. Derek... > -----Original Message----- > From: Sylvain Plante [SMTP:splante@rncan.gc.ca] > Sent: 29 April 1999 20:23 > To: Info-TCPware@PROCESS.COM > Subject: NFS problems > > Hi everybody, > > We have a strange problem with NFS client. We are using > OpenVMS 6.2-1H3, with TCPware 5.3 > > Here's what I have when I'm doing > the directory for the FIRST time: > > $ dir nfs11:[000000] > > 040I14.LST;1 0/0 > [0,0] > 040I15.LST;1 0/0 > [0,0] > 040I16.LST;1 0/0 > [0,0] > $ > > Here's what I get the second time. Just a few SECOND after the first > DIRECTORY command : > > $ dir nfs11:[000000] > > 040I14.LST;1 57/57 7-NOV-1995 07:42:25.00 > [PROD,BOSSE] > 040I15.LST;1 47/47 7-NOV-1995 07:42:25.00 > [PROD,BOSSE] > 040I16.LST;1 48/48 7-NOV-1995 07:42:25.00 > [PROD,BOSSE] > $ > > > Why is the first time I'm not receiving the right information. > Here's how the NFS disk 11 is mounted: > > NFSMOUNT/SYSTEM/CACHE=(DIR=00:00)1,ATT=00:00:01)/TRANS=TCP ROBIN > "/export/raid/bdtc" NFS11 BDTC > > > Sylvain Plante > splante@rncan.gc.ca *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 30 Apr 1999 01:45:31 -0400 From: leslie@clio.rice.edu () Reply-To: Info-TCPware@process.com Subject: Re: NFS problems Date: 30 Apr 1999 05:24:42 GMT Message-ID: <7gbeqq$g0q$1@joe.rice.edu> To: Info-TCPware@PROCESS.COM Derek Fage (Derekf@ITEXJSY.com) wrote: : I've been meaning to report a similar issue. : OpenVMS Alpha 7.1-1H2, TCPware 5.3-3 NFS client to a some Solaris 2.5.1 : UltraSparc systems. : Our developers have told me that sometimes they need to do a directory twice : before they see the latest files (even though the files were created on the : unix system 5-10 mins prior to rhe first time they did a directory). : This is one of those things on my "I'll get around to looking into" list : that was not impacting production (due to programs that are looking for : these files doing a directory lookup every 30 seconds when they expect to : find a file). : I have tried changing all sorts of different cache settings on the NFSMOUNT : command but to no avail. : Any hints / tips / tricks appreciated. Are the system clocks of the OpenVMS ALPHA and Solaris UltraSparc within two minutes of each other ? If not, try configuring NTP on both systems, as a permanent fix. --Jerry Leslie (my opinions are strictly my own) ================================================================================ Archive-Date: Fri, 30 Apr 1999 03:27:33 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017536A1@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NFS problems Date: Fri, 30 Apr 1999 08:26:35 +0100 MIME-Version: 1.0 Content-Type: text/plain One Solaris is 10 seconds out, the other is about 30 seconds out. Derek... > -----Original Message----- > From: leslie@clio.rice.edu [SMTP:leslie@clio.rice.edu] > Sent: 30 April 1999 06:25 > To: Info-TCPware@PROCESS.COM > Subject: Re: NFS problems > > Derek Fage (Derekf@ITEXJSY.com) wrote: > : I've been meaning to report a similar issue. > > : OpenVMS Alpha 7.1-1H2, TCPware 5.3-3 NFS client to a some Solaris 2.5.1 > : UltraSparc systems. > > : Our developers have told me that sometimes they need to do a directory > twice > : before they see the latest files (even though the files were created on > the > : unix system 5-10 mins prior to rhe first time they did a directory). > > : This is one of those things on my "I'll get around to looking into" list > : that was not impacting production (due to programs that are looking for > : these files doing a directory lookup every 30 seconds when they expect > to > : find a file). > > : I have tried changing all sorts of different cache settings on the > NFSMOUNT > : command but to no avail. > > : Any hints / tips / tricks appreciated. > > Are the system clocks of the OpenVMS ALPHA and Solaris UltraSparc within > two minutes of each other ? > > If not, try configuring NTP on both systems, as a permanent fix. > > --Jerry Leslie (my opinions are strictly my own) *********************************************************************** 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 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 to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 30 Apr 1999 11:50:49 -0400 Sender: lovejoy@process.com Date: Fri, 30 Apr 1999 11:50:27 -0400 From: lovejoy@process.com Reply-To: Info-TCPware@process.com To: Info-Tcpware@PROCESS.COM Message-ID: <009D7688.1A536CE3.68@process.com> Subject: Re: NFS problems For those of you who are experiencing NFS Client problems with recognition of files I suggest using the /CACHE=(READDIRECTORY) to force the client to read the directory contents and not just rely on the modify time of the directory(which isn't always updated) to determine when new files have been created. -Steve Lovejoy Process Software ================================================================================ Archive-Date: Fri, 30 Apr 1999 12:12:00 -0400 Message-ID: <49B21CD935D0D011B4980000F875254F017536B4@RDPEXC01> From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: NFS problems Date: Fri, 30 Apr 1999 17:06:58 +0100 MIME-Version: 1.0 Content-Type: text/plain Steve, We've already tried that and it did not seem to make any difference. Here's the NFSMOUNT command we use that tries (as I understand it) to get around any potential caching issues: $ NFSMOUNT /UID=7004 /GID=160 - /CACHE_TIMEOUT=(DIRECTORY=::01,ATTRIBUTE=::01,READ_DIRECTORY) - Any further ideas ? Derek... > -----Original Message----- > From: lovejoy@process.com [SMTP:lovejoy@process.com] > Sent: 30 April 1999 16:50 > To: Info-Tcpware@PROCESS.COM > Subject: Re: NFS problems > > > > For those of you who are experiencing NFS Client problems with recognition > of files I suggest using the /CACHE=(READDIRECTORY) to force the client > to read the directory contents and not just rely on the modify time of the > directory(which isn't always updated) to determine when new files have > been > created. > > -Steve Lovejoy > Process Software *********************************************************************** 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 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 to administrator@itexjsy.com. ***********************************************************************