Archive-Date: Thu, 1 Jul 1999 05:01:24 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E037A@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: urgent : Zone transfer dns failed Date: Thu, 1 Jul 1999 10:55:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I have a VAX VMS 6.2 TCPware 5.1-5. I want that vax be dns secondary = from a bind 8.1.1 dns server. I have the following message : %%%%%%%%%%%% NAMED 1-JUL-1999 10:31:00.03 %%%%%%%%%%%% %%TCPWARE_NAMED-I-XFRFAIL, named-xfer for "123.2.10.in-addr.arpa" = exited 2320 123.2.10.in-addr.arpa is the name of my reverse zone. And $ Exit 2320 =3D %SYSTEM-W-NOSUCHFILE, no such file. The file is present on the primary dns server. When I try with a = Solaris bind 4 secondary, the transfer zone is OK. I have installed the latest named patch on TCPware but the problem is = still here. I know that there are more recent tcpware versions (I have 5.3-2 = on other systems but is there a version which correct the problem). Regards, Pierre Clairembault ----------------------------- Banque CPR Architecture/r=E9seau mailto:pclairembault@cpr.fr tel : 01 45 96 23 49 Fax : 01 45 96 29 77 ================================================================================ Archive-Date: Thu, 1 Jul 1999 06:11:00 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E037B@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: "'Raymond, David'" CC: "'info-tcpware@process.com'" Subject: RE: urgent : Zone transfer dns failed Date: Thu, 1 Jul 1999 11:57:41 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEC3A8.288B3027" 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_01BEC3A8.288B3027 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David,=20 Ok it might help someone... Thanks. CF files nameserver.log and named_boot.txt (which is the copy of = named.boot) of the vax vms Origan. The bind 8 server is 10.15.127.6. Pierre -----Message d'origine----- De: Raymond, David [mailto:David.Raymond@essential.co.uk] Date: jeudi 1 juillet 1999 11:29 =C0: 'PCLAIREMBAULT@CPR.FR' Objet: RE: urgent : Zone transfer dns failed Pierre, I'd suggest you send a second posting to info-TCPware including your = full nameserver.log and your named.boot files. That might help someone to assist you. Regards David >-----Original Message----- >From: CLAIREMBAULT Pierre=20 >Sent: 01 July 1999 09:56 >To: info-tcpware@process.com >Subject: urgent : Zone transfer dns failed > > >Hello,=20 > >I have a VAX VMS 6.2 TCPware 5.1-5. I want that vax be dns=20 >secondary from a >bind 8.1.1 dns server. >I have the following message : > >%%%%%%%%%%%% NAMED 1-JUL-1999 10:31:00.03 %%%%%%%%%%%% >%%TCPWARE_NAMED-I-XFRFAIL, named-xfer for=20 >"123.2.10.in-addr.arpa" exited >2320 > >123.2.10.in-addr.arpa is the name of my reverse zone. > >And $ Exit 2320 =3D %SYSTEM-W-NOSUCHFILE, no such file. > >The file is present on the primary dns server. When I try with=20 >a Solaris >bind 4 secondary, the transfer zone is OK. > >I have installed the latest named patch on TCPware but the=20 >problem is still >here. I know that there are more recent tcpware versions (I=20 >have 5.3-2 on >other systems but is there a version which correct the problem). > >Regards, > >Pierre Clairembault >----------------------------- >Banque CPR >Architecture/r=E9seau >mailto:pclairembault@cpr.fr >tel : 01 45 96 23 49 >Fax : 01 45 96 29 77 > > ------_=_NextPart_000_01BEC3A8.288B3027 Content-Type: text/plain; name="named_boot.txt" Content-Disposition: attachment; filename="named_boot.txt" >ty tcpware_root:[tcpware.named]named.boot ; Data file to boot a primary name server. ; ; directory where all the data files are stored directory TCPWARE_ROOT:[TCPWARE.NAMED] ; ; type domain source host/file primary systeme.cpr.fr DB.SYSTEME ; secondary netid.cpr.fr 10.15.127.6 dbsecond.netid secondary 123.2.10.in-addr.arpa 10.15.127.6 dbsecond_123_2.10.rev primary 10.in-addr.arpa NAMED.REV ; primary 0.0.127.in-addr.arpa NAMED.LOCAL ; cluster aneth.systeme.cpr.fr cluster stachem.systeme.cpr.fr cluster time.systeme.cpr.fr cluster ile.systeme.cpr.fr ; secondary externes.cpr.fr 10.2.126.1 DBSECOND.EXTERNES secondary reseau.cpr.fr 10.2.126.1 DBSECOND.RESEAU secondary sdm.cpr.fr 10.2.126.1 DBSECOND.SDM secondary cpr.fr 10.2.126.1 DBSECOND.CPR_FR secondary 2.128.192.in-addr.arpa 10.2.126.1 DBSECOND_192_128_2.REV ; ; load the cache data last cache . NAMED.CA SYS_ORIGAN> ------_=_NextPart_000_01BEC3A8.288B3027 Content-Type: application/octet-stream; name="nameserver.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="nameserver.log" ty tcpware:nameserver.log $ if f$edit(f$getjpi("","username"),"upcase,collapse").eqs."PATROL"=20 $ endif $ Set NoOn $! $! This command procedure is always run when anybody on the entire = system $! logs in. It is equivalent to LOGIN.COM except that the instructions $! contained herein are executed everytime anyone on the VMS system $! logs in to their account. $! $! For interactive processes, turn on Control T, and set the terminal = type $! $ IF (F$MODE() .EQS. "INTERACTIVE") THEN SET CONTROL=3DT $ IF (F$MODE() .EQS. "INTERACTIVE") THEN SET TERMINAL/INQUIRE $! $! For MicroVAX systems only, use the command MOUNT/NOASSIST. $! $ IF (.NOT. F$TRNLNM("SYS$MICROVAX")) THEN GOTO SKIP_MICROVAX_COMMANDS $SKIP_MICROVAX_COMMANDS: $! $! Place your site-specific LOGIN commands below $ INFO:=3D=3D"SHO PROC/CONT/ID=3D" $ SNAP :=3D=3D"$ SYS$COMMON:[SYSMGR.UTILITY]SNAP" $ SW*ING:=3D=3D"$ SYS$COMMON:[SYSMGR.UTILITY]SWING" $ VFE :=3D=3D"$ SYS$COMMON:[SYSMGR.UTILITY]VFE" $ CHKMAIL:=3D=3D"$ SYS$COMMON:[SYSMGR.UTILITY]CHKMAIL" $ MYC:=3D=3D$SYS$COMMON:[SYSMGR.UTILITY]RECALL $! $! Declaration des services tcp/ip - pc 08/07/96 $ ping :=3D=3D $Tcpware:ping $ telnet :=3D=3D $Tcpware:telnet $ rlogin :=3D=3D $Tcpware:rlogin $ ftp :=3D=3D $Tcpware:ftp $ rcp :=3D=3D $Tcpware:rcp $ rsh :=3D=3D $Tcpware:rsh $ rlogin :=3D=3D $Tcpware:rlogin $ nfsmount :=3D=3D $Tcpware:nfsmount $ nfsdismount :=3D=3D $Tcpware:nfsdismount $ nslookup :=3D=3D $Tcpware:nslookup $ netcu :=3D=3D $Tcpware:netcu $! $ Exit $! Copyright (c) 1989-1996, Process Software Corporation $ SET NOON $! SET PROCESS/DUMP $ NAMED_ZXFR:=3D=3D$TCPWARE:NAMED_ZXFR.EXE $START: $ RUN TCPWARE:NAMED.EXE NAMED TCPware(R) for OpenVMS V5.1-5 Copyright (c) 1996 Process = Software Corpor ation %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:51.28 %%%%%%%%%%%% %%%%%%%%%%%% NAMED Process ID =3D 20919EA3 %%%%%%%%%%%% %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:51.29 %%%%%%%%%%%% %%TCPWARE_NAMED-I-STARTUP, domain name server started %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:51.36 %%%%%%%%%%%% %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:52.26 %%%%%%%%%%%% %%TCPWARE_NAMED-I-OSMISS, DB.SYSTEME: line 1243: OS-type missing %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:52.26 %%%%%%%%%%%% %%TCPWARE_NAMED-I-OSMISS, DB.SYSTEME: line 1245: OS-type missing %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:52.26 %%%%%%%%%%%% %%TCPWARE_NAMED-I-OSMISS, DB.SYSTEME: line 1247: OS-type missing %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:52.39 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, primary zone "systeme.cpr.fr" loaded = (serial=20 99070100) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:52.52 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "netid.cpr.fr" loaded = (serial=20 1999063004) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:54.38 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, primary zone "10.in-addr.arpa" loaded = (serial=20 99070100) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:54.46 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, primary zone "0.0.127.in-addr.arpa" loaded = (serial=20 95102300) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:54.60 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "externes.cpr.fr" loaded = (serial=20 99063001) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:54.66 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "reseau.cpr.fr" loaded = (serial=20 999060000) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:54.78 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "sdm.cpr.fr" loaded (serial = 99063000) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:54.87 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "cpr.fr" loaded (serial = 99062101) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:54.97 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "2.128.192.in-addr.arpa" = loaded=20 (serial 98060900) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:55.03 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, cache zone "" loaded (serial 0) %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:55.07 %%%%%%%%%%%% %%TCPWARE_NAMED-I-MAIN, Ready to answer queries. %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:59.37 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 209028A4 to transfer zone=20 123.2.10.in-addr.arpa %%%%%%%%%%%% NAMED 1-JUL-1999 10:30:59.47 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 208EF4A5 to transfer zone=20 2.128.192.in-addr.arpa %SYSTEM-W-NOSUCHFILE, no such file %%%%%%%%%%%% NAMED 1-JUL-1999 10:31:00.03 %%%%%%%%%%%% %%TCPWARE_NAMED-I-XFRFAIL, named-xfer for "123.2.10.in-addr.arpa" = exited 2320 %%%%%%%%%%%% NAMED 1-JUL-1999 10:31:00.17 %%%%%%%%%%%% %%TCPWARE_NAMED-I-XFERSUCCESS, zone 2.128.192.in-addr.arpa transferred=20 successfully %%%%%%%%%%%% NAMED 1-JUL-1999 10:31:00.25 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "2.128.192.in-addr.arpa" = loaded=20 (serial 98060900) %%%%%%%%%%%% NAMED 1-JUL-1999 10:46:00.13 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 209273B8 to transfer zone=20 123.2.10.in-addr.arpa %SYSTEM-W-NOSUCHFILE, no such file %%%%%%%%%%%% NAMED 1-JUL-1999 11:01:00.81 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 209363C0 to transfer zone=20 123.2.10.in-addr.arpa %SYSTEM-W-NOSUCHFILE, no such file %%%%%%%%%%%% NAMED 1-JUL-1999 11:16:00.81 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 2093AE72 to transfer zone = netid.cpr.f r %%%%%%%%%%%% NAMED 1-JUL-1999 11:16:00.94 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 20936176 to transfer zone=20 123.2.10.in-addr.arpa %SYSTEM-W-NOSUCHFILE, no such file %%%%%%%%%%%% NAMED 1-JUL-1999 11:31:01.35 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 2092715E to transfer zone=20 123.2.10.in-addr.arpa %SYSTEM-W-NOSUCHFILE, no such file SYS_ORIGAN> ------_=_NextPart_000_01BEC3A8.288B3027-- ================================================================================ Archive-Date: Thu, 1 Jul 1999 06:50:08 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor Query Date: Thu, 1 Jul 1999 11:45:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Bernie. It's the 401 error that I am particularly interested in. I setup the new key entry and restarted the server, but now autentication is never performed (whenever I try to access a page that requires authentication, instead of getting prompted for a username and password 3 times prior to displaying the original error I get redirected straight to my new 401error.html page.) We use an external DLL for authentication (as we authenticate against UAF for users and groups/identifiers). Any ideas ? Cheers, Derek... PS - Sorry for the long response - I've just returned from vacation. > -----Original Message----- > From: volz@process.com [SMTP:volz@process.com] > Sent: 21 June 1999 19:30 > To: Info-TCPware@PROCESS.COM > Subject: Re: Purveyor Query > > In article , Derek Fage > writes: > > Hi there, > > > > I'd like to find out if it is possible to modify my Purveyor Wenserver > (2.0) > > so that when user authentication fails I can redirect the server to > another > > page instead of displaying the standard "Unauthorized -- authentication > > failed. HTTP status code: 401" message. > > > > Regards, > > > > Derek... > > *** WARNING !!! > > The following information is being provided "as is" for Purveyor for > OpenVMS Version 2.0 and later. No support is given for these features. > If these features are used and you have a problem with Purveyor, disable > use of these features and retest before reporting the problem. > > These features are undocumented and unsupported. > > ------------------------------------------------------------------------ > > Purveyor now supports error processing documents. Instead of returning > the fixed (internal) error, Purveyor can instead return a customized > message. Basiscally, Purveyor "redirects" to the error document, if > configured. This document may be a .HTML, .HTP, or other file or CGI. > The document that is specified must be GLOBALLY accessible by all > virtual servers for that database configuration. If you use a file of > /error/404error.html (for example), then there must be an error > directory in each virtual servers default data directory! (Or, a virtual > path of "error" configured.) > > If the indicated document can not be found or accessed, that error is > returned to the user (ie, recursion on error handling is not allowed). > > The log file will always log the ORIGINAL status. > > NOTICE: This is *NOT* documented and this support can NOT be configured > via RSM. This support hasn't been throughly tested and there may be > problems in using it. > > WARNING: Do not use a DLL that requests deferred processing! This is not > supported and will cause severe problems (probably ACCVIOs). > > NOTICE: If a CGI or DLL is run, it can get the original document URL > from the WWW_REQUEST_LINE environment variable. No error code is passed > to it (that can be solved by having a separate CGI/DLL for each error > code). > > The key under which these entries are stored is: > SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments > > And, the values under this key are as follows: > > Value xx > Name: 404 > Type: REG_SZ > Data: /~error/notfound.html > > where Name is the error code and Data is the new URL (use of a virtual > path is recommended especially when using the virtual server support). > > You can set these entries up as follows: > > $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch > $ UTILITY UPDATE database - > "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments" - > "error-code" "error-URL" "REG_SZ" > > where arch is either VAX or AXP and database is the configuration > database file's name. Note that the quotes, where shown above, are > required. > > ------------------------------------------------------------------------ > > Three special parameters are now supported in the configuration database. > Please note that NO configuration (RSM) is provided for these parameters > and they should not normally be needed. However, in some special > circumstances, there may be a reason to tune them. > > To tune these values, one must manually add them (using a text editor) > to the configuration database file. > > You can also add these using the following sequence: > > $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch > $ UTILITY UPDATE database - > "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > "SO_BACKLOG" 256 "REG_DWORD" > $ UTILITY UPDATE database - > "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > "SO_SNDBUF" 16384 "REG_DWORD" > $ UTILITY UPDATE database - > "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > "SO_RCVBUF" 16384 "REG_DWORD" > > where arch is either VAX or AXP and database is the configuration > database file's name. Note that the quotes, where shown above, are > required. > > They are SYSTEM\CurrentControlSet\Services\Purveyor\Parameters: > > Value xx > Name: SO_BACKLOG > Type: REG_DWORD > Data: 256 > > Value xx+1 > Name: SO_SNDBUF > Type: REG_DWORD > Data: 16384 > > Value xx+2 > Name: SO_RCVBUF > Type: REG_DWORD > Data: 16384 > > > SO_BACKLOG allows one to set the connection backlog limit. This values > is passed to the TCP/IP implementation to set the connection backlog. By > default, Purveyor uses 256. > > SO_SNDBUF and SO_RCVBUF allows one to set the socket send and receive > buffer limits (see setsockopt, SO_SNDBUF and SO_RCVBUF for complete > details). By default, Purveyor uses 16384 for each of these. > > > Reasons for wanting to tune these values could include: > > SO_BACKLOG > If a TCP/IP implementation does not allow (and does not > silently ignore) a value larger than its backlog limit. > > SO_SNDBUF/SO_RCVBUF > To reduce the potential buffer space needed on a system for > HTTP connections. With the 16384 default, having lots of slow > or hung connections can result in significant buffer usage. > Reducing these values can help avoid this at a decrease in > network throughput. This is especially a consideration for > TCP/IP Services for OpenVMS. ================================================================================ Archive-Date: Thu, 1 Jul 1999 08:06:35 -0400 Sender: schreiber@process.com Date: Thu, 1 Jul 1999 08:03:35 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009DA720.AECA4CDB.69@process.com> Subject: RE: urgent : Zone transfer dns failed CLAIREMBAULT Pierre writes: > >>And $ Exit 2320 =3D %SYSTEM-W-NOSUCHFILE, no such file. >> >>The file is present on the primary dns server. When I try with a Solaris >>bind 4 secondary, the transfer zone is OK. >> >secondary 123.2.10.in-addr.arpa 10.15.127.6 dbsecond_123_2.10.rev When the nameserver transferred the zone it creates a temporary file, then it renames that temporary file to the backup file. Somewhere along the line it failed... the reason being because of the file name. Please change to dbsecond_123_2_10.rev from dbsecond_123_2.10.rev and see if you still have a problem. (VMS only allows 1 dot) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 1 Jul 1999 08:09:38 -0400 Date: Thu, 01 Jul 1999 07:58:17 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: VMSLPRSMB_V533P030 To: TCPware-Announce@PROCESS.COM Message-ID: <01JD1JYICDOI000BXD@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: VMSLPRSMB_V533P030 Description: Assorted VMS LPR symbiont fixes Release date: 1-JUL-1999 Versions: 5.3-3,5.3-2 ftp://ftp.process.com/support/53_3/vmslprsmb_v533p030.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- -------------------------------------------------------------------------- VMSLPRSMB Patch kit (revision 3.0) for TCPware version 5.3-3 29-Jun-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of the VMSLPR symbiont for TCPware for OpenVMS. Applicable TCPware and VMS versions: TCPware 5.2-3 or higher on all supported versions of VAX/VMS and OpenVMS. The LPS component must be shut down before installing and restarted once the installation is complete. The following changes have been made: 1) When the domain name of the local system is longer than 25 characters, printing will fail with corrupted control file. This problem is fixed. 2) When file consists only of form feed characters and the length of the file is less than or equal to 2 bytes, symbiont goes to stalled state. This no longer happens. 3) Temporary data files are now deleted if the network connection is lost during printing. 4) Fixed "unexpected symbiont process termination" under certain conditions. 5) By default the VMSLPR symbiont creates flag pages by generating them locally using the VMS print symbiont and suppressing banner pages generated by the LPD server. An enhancement was made that the VMSLPR symbiont can now optinally request that the remote LPD server generate the banner page. To enable this functionality on a specific queue, define the logical: $ DEFINE/SYS/EXEC - TCPWARE_VMSLPRSMB__REMOTE_BANNER - "TRUE" To enable this functionality on all VMSLPR symbiont queues, define the logical : $ DEFINE/SYS/EXEC - TCPWARE_VMSLPRSMB_*_REMOTE_BANNER - "TRUE" 6) Changes have been made to code that handles the removal of excess carriage control from print jobs, which would occasionally remove too many characters. Support has also been added for a new logical, TCPWARE_VMSLPRSMB__TRIMTAIL. If this logical is defined, it is a numeric value indicating the number of characters to remove from the end of each print job. If not specified, the default value is 2. 7) In previous releases the VMSLPR symbiont would open the connection to the printer before processing the file. With some printers, this would result in a timeout when large print jobs were submitted. This behaviour has been changed and the connection will now be made after processing the file. If the previous functionality is still desired, it can be enabled using the TCPWARE_VMSLPRSMB__PRECONN (preconnect) logical. To enable this functionality on all VMSLPR symbiont queues, define the logical : $ DEFINE/SYS/EXEC - TCPWARE_VMSLPRSMB_*_PRECONN - "TRUE" The old version of TCPWARE_VMSLPRSMB will be renamed to SYS$COMMON:[SYSEXE]TCPWARE_VMSLPRSMB.EXE_OLD Once installed, you may undo this patch by shutting down the LPS component, renaming the file back to SYS$COMMON:[SYSEXE]TCPWARE_VMSLPRSMB.EXE and restarting the LPS component. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 1 Jul 1999 08:39:06 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E037C@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: urgent : Zone transfer dns failed Date: Thu, 1 Jul 1999 14:34:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There was something wrong in the name dbsecond_123_2_10.rev (I had only = one dot). However, I have changed the name in test.rev. Now, I have no error in nameserver.log but my file test.rev is empty!=20 I have tried with another zone zzz.cpr.fr and the transfer gives an = empty file too. Another idea? Regards, Pierre -----Message d'origine----- De: Jeff Schreiber [mailto:schreiber@process.com] Date: jeudi 1 juillet 1999 14:04 =C0: Info-TCPware@process.com Cc: schreiber@process.com Objet: RE: urgent : Zone transfer dns failed CLAIREMBAULT Pierre writes: > >>And $ Exit 2320 =3D3D %SYSTEM-W-NOSUCHFILE, no such file. >> >>The file is present on the primary dns server. When I try with a = Solaris >>bind 4 secondary, the transfer zone is OK. >> >secondary 123.2.10.in-addr.arpa 10.15.127.6 = dbsecond_123_2.10.rev When the nameserver transferred the zone it creates a temporary = file, then it renames that temporary file to the backup file. Somewhere along the line it failed... the reason being because of = the file name. Please change to dbsecond_123_2_10.rev from dbsecond_123_2.10.rev = and see if you still have a problem. (VMS only allows 1 dot) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 1 Jul 1999 09:59:40 -0400 Subject: RE: Purveyor Query Message-ID: <1999Jul1.091911@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Jul 99 09:19:11 -0400 To: Info-TCPware@PROCESS.COM To do the 401 page, you really need to use a CGI that returns the 401 status to the browser. If you redirect it to a document, it will send the document that is a 200 reply, not a 401 reply. So, set up a simple CGI that sends a "Status: 401" to indicate that that is the status (not the 200). Then, you can send text that gives the error you want (though a browser may not display it because the 401 status says to ask for authentication). If it doesn't do what you want, then don't redirect the 401 entry. In article , Derek Fage writes: > Thanks Bernie. > > It's the 401 error that I am particularly interested in. > > I setup the new key entry and restarted the server, but now autentication is > never performed (whenever I try to access a page that requires > authentication, instead of getting prompted for a username and password 3 > times prior to displaying the original error I get redirected straight to my > new 401error.html page.) > > We use an external DLL for authentication (as we authenticate against UAF > for users and groups/identifiers). > > Any ideas ? > > Cheers, > > Derek... > > PS - Sorry for the long response - I've just returned from vacation. > > >> -----Original Message----- >> From: volz@process.com [SMTP:volz@process.com] >> Sent: 21 June 1999 19:30 >> To: Info-TCPware@PROCESS.COM >> Subject: Re: Purveyor Query >> >> In article , Derek Fage >> writes: >> > Hi there, >> > >> > I'd like to find out if it is possible to modify my Purveyor Wenserver >> (2.0) >> > so that when user authentication fails I can redirect the server to >> another >> > page instead of displaying the standard "Unauthorized -- authentication >> > failed. HTTP status code: 401" message. >> > >> > Regards, >> > >> > Derek... >> >> *** WARNING !!! >> >> The following information is being provided "as is" for Purveyor for >> OpenVMS Version 2.0 and later. No support is given for these features. >> If these features are used and you have a problem with Purveyor, disable >> use of these features and retest before reporting the problem. >> >> These features are undocumented and unsupported. >> >> ------------------------------------------------------------------------ >> >> Purveyor now supports error processing documents. Instead of returning >> the fixed (internal) error, Purveyor can instead return a customized >> message. Basiscally, Purveyor "redirects" to the error document, if >> configured. This document may be a .HTML, .HTP, or other file or CGI. >> The document that is specified must be GLOBALLY accessible by all >> virtual servers for that database configuration. If you use a file of >> /error/404error.html (for example), then there must be an error >> directory in each virtual servers default data directory! (Or, a virtual >> path of "error" configured.) >> >> If the indicated document can not be found or accessed, that error is >> returned to the user (ie, recursion on error handling is not allowed). >> >> The log file will always log the ORIGINAL status. >> >> NOTICE: This is *NOT* documented and this support can NOT be configured >> via RSM. This support hasn't been throughly tested and there may be >> problems in using it. >> >> WARNING: Do not use a DLL that requests deferred processing! This is not >> supported and will cause severe problems (probably ACCVIOs). >> >> NOTICE: If a CGI or DLL is run, it can get the original document URL >> from the WWW_REQUEST_LINE environment variable. No error code is passed >> to it (that can be solved by having a separate CGI/DLL for each error >> code). >> >> The key under which these entries are stored is: >> SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments >> >> And, the values under this key are as follows: >> >> Value xx >> Name: 404 >> Type: REG_SZ >> Data: /~error/notfound.html >> >> where Name is the error code and Data is the new URL (use of a virtual >> path is recommended especially when using the virtual server support). >> >> You can set these entries up as follows: >> >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch >> $ UTILITY UPDATE database - >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments" - >> "error-code" "error-URL" "REG_SZ" >> >> where arch is either VAX or AXP and database is the configuration >> database file's name. Note that the quotes, where shown above, are >> required. >> >> ------------------------------------------------------------------------ >> >> Three special parameters are now supported in the configuration database. >> Please note that NO configuration (RSM) is provided for these parameters >> and they should not normally be needed. However, in some special >> circumstances, there may be a reason to tune them. >> >> To tune these values, one must manually add them (using a text editor) >> to the configuration database file. >> >> You can also add these using the following sequence: >> >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch >> $ UTILITY UPDATE database - >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - >> "SO_BACKLOG" 256 "REG_DWORD" >> $ UTILITY UPDATE database - >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - >> "SO_SNDBUF" 16384 "REG_DWORD" >> $ UTILITY UPDATE database - >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - >> "SO_RCVBUF" 16384 "REG_DWORD" >> >> where arch is either VAX or AXP and database is the configuration >> database file's name. Note that the quotes, where shown above, are >> required. >> >> They are SYSTEM\CurrentControlSet\Services\Purveyor\Parameters: >> >> Value xx >> Name: SO_BACKLOG >> Type: REG_DWORD >> Data: 256 >> >> Value xx+1 >> Name: SO_SNDBUF >> Type: REG_DWORD >> Data: 16384 >> >> Value xx+2 >> Name: SO_RCVBUF >> Type: REG_DWORD >> Data: 16384 >> >> >> SO_BACKLOG allows one to set the connection backlog limit. This values >> is passed to the TCP/IP implementation to set the connection backlog. By >> default, Purveyor uses 256. >> >> SO_SNDBUF and SO_RCVBUF allows one to set the socket send and receive >> buffer limits (see setsockopt, SO_SNDBUF and SO_RCVBUF for complete >> details). By default, Purveyor uses 16384 for each of these. >> >> >> Reasons for wanting to tune these values could include: >> >> SO_BACKLOG >> If a TCP/IP implementation does not allow (and does not >> silently ignore) a value larger than its backlog limit. >> >> SO_SNDBUF/SO_RCVBUF >> To reduce the potential buffer space needed on a system for >> HTTP connections. With the 16384 default, having lots of slow >> or hung connections can result in significant buffer usage. >> Reducing these values can help avoid this at a decrease in >> network throughput. This is especially a consideration for >> TCP/IP Services for OpenVMS. ================================================================================ Archive-Date: Thu, 1 Jul 1999 10:40:32 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor Query Date: Thu, 1 Jul 1999 15:36:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bernie, I do not understand how to do that. The authentication is done by the server, not the CGI. We have CGI programs and folders with HTML docs as well as zip files etc... that need to be protected, so we run a modified version of FILE_AUTH.C authentication DLL that you provide in the samples/dll directory. I can only presume that this is buried in the Purveyor server code itself somewhere to make the call to the authentication DLL and interpret the response to decide whether to procede or to return a 401 error. What I really do not understand is why when I put the new key entry in that I never even get prompted for a username password. Is there no way of getting around this ? Cheers, Derek (hopeful.........) > -----Original Message----- > From: volz@process.com [SMTP:volz@process.com] > Sent: 01 July 1999 14:19 > To: Info-TCPware@PROCESS.COM > Subject: RE: Purveyor Query > > To do the 401 page, you really need to use a CGI that returns the 401 > status to the browser. If you redirect it to a document, it will send > the document that is a 200 reply, not a 401 reply. > > So, set up a simple CGI that sends a "Status: 401" to indicate that that > is the status (not the 200). Then, you can send text that gives the > error you want (though a browser may not display it because the 401 > status says to ask for authentication). > > If it doesn't do what you want, then don't redirect the 401 entry. > > > In article , Derek Fage > writes: > > Thanks Bernie. > > > > It's the 401 error that I am particularly interested in. > > > > I setup the new key entry and restarted the server, but now > autentication is > > never performed (whenever I try to access a page that requires > > authentication, instead of getting prompted for a username and password > 3 > > times prior to displaying the original error I get redirected straight > to my > > new 401error.html page.) > > > > We use an external DLL for authentication (as we authenticate against > UAF > > for users and groups/identifiers). > > > > Any ideas ? > > > > Cheers, > > > > Derek... > > > > PS - Sorry for the long response - I've just returned from vacation. > > > > > >> -----Original Message----- > >> From: volz@process.com [SMTP:volz@process.com] > >> Sent: 21 June 1999 19:30 > >> To: Info-TCPware@PROCESS.COM > >> Subject: Re: Purveyor Query > >> > >> In article , Derek Fage > >> writes: > >> > Hi there, > >> > > >> > I'd like to find out if it is possible to modify my Purveyor > Wenserver > >> (2.0) > >> > so that when user authentication fails I can redirect the server to > >> another > >> > page instead of displaying the standard "Unauthorized -- > authentication > >> > failed. HTTP status code: 401" message. > >> > > >> > Regards, > >> > > >> > Derek... > >> > >> *** WARNING !!! > >> > >> The following information is being provided "as is" for Purveyor for > >> OpenVMS Version 2.0 and later. No support is given for these features. > >> If these features are used and you have a problem with Purveyor, > disable > >> use of these features and retest before reporting the problem. > >> > >> These features are undocumented and unsupported. > >> > >> > ------------------------------------------------------------------------ > >> > >> Purveyor now supports error processing documents. Instead of returning > >> the fixed (internal) error, Purveyor can instead return a customized > >> message. Basiscally, Purveyor "redirects" to the error document, if > >> configured. This document may be a .HTML, .HTP, or other file or CGI. > >> The document that is specified must be GLOBALLY accessible by all > >> virtual servers for that database configuration. If you use a file of > >> /error/404error.html (for example), then there must be an error > >> directory in each virtual servers default data directory! (Or, a > virtual > >> path of "error" configured.) > >> > >> If the indicated document can not be found or accessed, that error is > >> returned to the user (ie, recursion on error handling is not allowed). > >> > >> The log file will always log the ORIGINAL status. > >> > >> NOTICE: This is *NOT* documented and this support can NOT be configured > >> via RSM. This support hasn't been throughly tested and there may be > >> problems in using it. > >> > >> WARNING: Do not use a DLL that requests deferred processing! This is > not > >> supported and will cause severe problems (probably ACCVIOs). > >> > >> NOTICE: If a CGI or DLL is run, it can get the original document URL > >> from the WWW_REQUEST_LINE environment variable. No error code is passed > >> to it (that can be solved by having a separate CGI/DLL for each error > >> code). > >> > >> The key under which these entries are stored is: > >> SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments > >> > >> And, the values under this key are as follows: > >> > >> Value xx > >> Name: 404 > >> Type: REG_SZ > >> Data: /~error/notfound.html > >> > >> where Name is the error code and Data is the new URL (use of a virtual > >> path is recommended especially when using the virtual server support). > >> > >> You can set these entries up as follows: > >> > >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch > >> $ UTILITY UPDATE database - > >> > "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments" - > >> "error-code" "error-URL" "REG_SZ" > >> > >> where arch is either VAX or AXP and database is the configuration > >> database file's name. Note that the quotes, where shown above, are > >> required. > >> > >> > ------------------------------------------------------------------------ > >> > >> Three special parameters are now supported in the configuration > database. > >> Please note that NO configuration (RSM) is provided for these > parameters > >> and they should not normally be needed. However, in some special > >> circumstances, there may be a reason to tune them. > >> > >> To tune these values, one must manually add them (using a text editor) > >> to the configuration database file. > >> > >> You can also add these using the following sequence: > >> > >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch > >> $ UTILITY UPDATE database - > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > >> "SO_BACKLOG" 256 "REG_DWORD" > >> $ UTILITY UPDATE database - > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > >> "SO_SNDBUF" 16384 "REG_DWORD" > >> $ UTILITY UPDATE database - > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > >> "SO_RCVBUF" 16384 "REG_DWORD" > >> > >> where arch is either VAX or AXP and database is the configuration > >> database file's name. Note that the quotes, where shown above, are > >> required. > >> > >> They are SYSTEM\CurrentControlSet\Services\Purveyor\Parameters: > >> > >> Value xx > >> Name: SO_BACKLOG > >> Type: REG_DWORD > >> Data: 256 > >> > >> Value xx+1 > >> Name: SO_SNDBUF > >> Type: REG_DWORD > >> Data: 16384 > >> > >> Value xx+2 > >> Name: SO_RCVBUF > >> Type: REG_DWORD > >> Data: 16384 > >> > >> > >> SO_BACKLOG allows one to set the connection backlog limit. This values > >> is passed to the TCP/IP implementation to set the connection backlog. > By > >> default, Purveyor uses 256. > >> > >> SO_SNDBUF and SO_RCVBUF allows one to set the socket send and receive > >> buffer limits (see setsockopt, SO_SNDBUF and SO_RCVBUF for complete > >> details). By default, Purveyor uses 16384 for each of these. > >> > >> > >> Reasons for wanting to tune these values could include: > >> > >> SO_BACKLOG > >> If a TCP/IP implementation does not allow (and does not > >> silently ignore) a value larger than its backlog limit. > >> > >> SO_SNDBUF/SO_RCVBUF > >> To reduce the potential buffer space needed on a system for > >> HTTP connections. With the 16384 default, having lots of slow > >> or hung connections can result in significant buffer usage. > >> Reducing these values can help avoid this at a decrease in > >> network throughput. This is especially a consideration for > >> TCP/IP Services for OpenVMS. ================================================================================ Archive-Date: Thu, 1 Jul 1999 11:04:08 -0400 Message-ID: From: Derek Fage Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Purveyor Query Date: Thu, 1 Jul 1999 15:59:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hmmm, Having turned on tracing and examined the worker log files, it would appear that what happens is that the when a connection is received that has no authentication, the worker will respond with a 401 error. It would seem that the browser will then prompt for the username / password combination for the realm and try again (three times) before displaying the error. I can see how this could create a problem for the worker process in that it would need to keep a count of failed connection attempts so that it can send back a 401 to force the browser to prompt the user for username / password pairs prior to sending performing a redirection to another page. Can you think of any way of working around this (sounds a bit tricky) ? Cheers, Derek... > -----Original Message----- > From: Derek Fage [SMTP:DerekF@itexjsy.com] > Sent: 01 July 1999 15:36 > To: 'Info-TCPware@process.com' > Subject: RE: Purveyor Query > > Bernie, > > I do not understand how to do that. The authentication is done by the > server, not the CGI. We have CGI programs and folders with HTML docs as > well > as zip files etc... that need to be protected, so we run a modified > version > of FILE_AUTH.C authentication DLL that you provide in the samples/dll > directory. > > I can only presume that this is buried in the Purveyor server code itself > somewhere to make the call to the authentication DLL and interpret the > response to decide whether to procede or to return a 401 error. What I > really do not understand is why when I put the new key entry in that I > never > even get prompted for a username password. > > Is there no way of getting around this ? > > Cheers, > > Derek (hopeful.........) > > > -----Original Message----- > > From: volz@process.com [SMTP:volz@process.com] > > Sent: 01 July 1999 14:19 > > To: Info-TCPware@PROCESS.COM > > Subject: RE: Purveyor Query > > > > To do the 401 page, you really need to use a CGI that returns the 401 > > status to the browser. If you redirect it to a document, it will send > > the document that is a 200 reply, not a 401 reply. > > > > So, set up a simple CGI that sends a "Status: 401" to indicate that that > > is the status (not the 200). Then, you can send text that gives the > > error you want (though a browser may not display it because the 401 > > status says to ask for authentication). > > > > If it doesn't do what you want, then don't redirect the 401 entry. > > > > > > In article , Derek Fage > > writes: > > > Thanks Bernie. > > > > > > It's the 401 error that I am particularly interested in. > > > > > > I setup the new key entry and restarted the server, but now > > autentication is > > > never performed (whenever I try to access a page that requires > > > authentication, instead of getting prompted for a username and > password > > 3 > > > times prior to displaying the original error I get redirected straight > > to my > > > new 401error.html page.) > > > > > > We use an external DLL for authentication (as we authenticate against > > UAF > > > for users and groups/identifiers). > > > > > > Any ideas ? > > > > > > Cheers, > > > > > > Derek... > > > > > > PS - Sorry for the long response - I've just returned from vacation. > > > > > > > > >> -----Original Message----- > > >> From: volz@process.com [SMTP:volz@process.com] > > >> Sent: 21 June 1999 19:30 > > >> To: Info-TCPware@PROCESS.COM > > >> Subject: Re: Purveyor Query > > >> > > >> In article , Derek > Fage > > >> writes: > > >> > Hi there, > > >> > > > >> > I'd like to find out if it is possible to modify my Purveyor > > Wenserver > > >> (2.0) > > >> > so that when user authentication fails I can redirect the server to > > >> another > > >> > page instead of displaying the standard "Unauthorized -- > > authentication > > >> > failed. HTTP status code: 401" message. > > >> > > > >> > Regards, > > >> > > > >> > Derek... > > >> > > >> *** WARNING !!! > > >> > > >> The following information is being provided "as is" for Purveyor for > > >> OpenVMS Version 2.0 and later. No support is given for these > features. > > >> If these features are used and you have a problem with Purveyor, > > disable > > >> use of these features and retest before reporting the problem. > > >> > > >> These features are undocumented and unsupported. > > >> > > >> > > ------------------------------------------------------------------------ > > >> > > >> Purveyor now supports error processing documents. Instead of > returning > > >> the fixed (internal) error, Purveyor can instead return a customized > > >> message. Basiscally, Purveyor "redirects" to the error document, if > > >> configured. This document may be a .HTML, .HTP, or other file or CGI. > > >> The document that is specified must be GLOBALLY accessible by all > > >> virtual servers for that database configuration. If you use a file of > > >> /error/404error.html (for example), then there must be an error > > >> directory in each virtual servers default data directory! (Or, a > > virtual > > >> path of "error" configured.) > > >> > > >> If the indicated document can not be found or accessed, that error is > > >> returned to the user (ie, recursion on error handling is not > allowed). > > >> > > >> The log file will always log the ORIGINAL status. > > >> > > >> NOTICE: This is *NOT* documented and this support can NOT be > configured > > >> via RSM. This support hasn't been throughly tested and there may be > > >> problems in using it. > > >> > > >> WARNING: Do not use a DLL that requests deferred processing! This is > > not > > >> supported and will cause severe problems (probably ACCVIOs). > > >> > > >> NOTICE: If a CGI or DLL is run, it can get the original document URL > > >> from the WWW_REQUEST_LINE environment variable. No error code is > passed > > >> to it (that can be solved by having a separate CGI/DLL for each error > > >> code). > > >> > > >> The key under which these entries are stored is: > > >> SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments > > >> > > >> And, the values under this key are as follows: > > >> > > >> Value xx > > >> Name: 404 > > >> Type: REG_SZ > > >> Data: /~error/notfound.html > > >> > > >> where Name is the error code and Data is the new URL (use of a > virtual > > >> path is recommended especially when using the virtual server > support). > > >> > > >> You can set these entries up as follows: > > >> > > >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch > > >> $ UTILITY UPDATE database - > > >> > > "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments" - > > >> "error-code" "error-URL" "REG_SZ" > > >> > > >> where arch is either VAX or AXP and database is the configuration > > >> database file's name. Note that the quotes, where shown above, are > > >> required. > > >> > > >> > > ------------------------------------------------------------------------ > > >> > > >> Three special parameters are now supported in the configuration > > database. > > >> Please note that NO configuration (RSM) is provided for these > > parameters > > >> and they should not normally be needed. However, in some special > > >> circumstances, there may be a reason to tune them. > > >> > > >> To tune these values, one must manually add them (using a text > editor) > > >> to the configuration database file. > > >> > > >> You can also add these using the following sequence: > > >> > > >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch > > >> $ UTILITY UPDATE database - > > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > > >> "SO_BACKLOG" 256 "REG_DWORD" > > >> $ UTILITY UPDATE database - > > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > > >> "SO_SNDBUF" 16384 "REG_DWORD" > > >> $ UTILITY UPDATE database - > > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - > > >> "SO_RCVBUF" 16384 "REG_DWORD" > > >> > > >> where arch is either VAX or AXP and database is the configuration > > >> database file's name. Note that the quotes, where shown above, are > > >> required. > > >> > > >> They are SYSTEM\CurrentControlSet\Services\Purveyor\Parameters: > > >> > > >> Value xx > > >> Name: SO_BACKLOG > > >> Type: REG_DWORD > > >> Data: 256 > > >> > > >> Value xx+1 > > >> Name: SO_SNDBUF > > >> Type: REG_DWORD > > >> Data: 16384 > > >> > > >> Value xx+2 > > >> Name: SO_RCVBUF > > >> Type: REG_DWORD > > >> Data: 16384 > > >> > > >> > > >> SO_BACKLOG allows one to set the connection backlog limit. This > values > > >> is passed to the TCP/IP implementation to set the connection backlog. > > By > > >> default, Purveyor uses 256. > > >> > > >> SO_SNDBUF and SO_RCVBUF allows one to set the socket send and receive > > >> buffer limits (see setsockopt, SO_SNDBUF and SO_RCVBUF for complete > > >> details). By default, Purveyor uses 16384 for each of these. > > >> > > >> > > >> Reasons for wanting to tune these values could include: > > >> > > >> SO_BACKLOG > > >> If a TCP/IP implementation does not allow (and does not > > >> silently ignore) a value larger than its backlog limit. > > >> > > >> SO_SNDBUF/SO_RCVBUF > > >> To reduce the potential buffer space needed on a system for > > >> HTTP connections. With the 16384 default, having lots of slow > > >> or hung connections can result in significant buffer usage. > > >> Reducing these values can help avoid this at a decrease in > > >> network throughput. This is especially a consideration for > > >> TCP/IP Services for OpenVMS. ================================================================================ Archive-Date: Fri, 2 Jul 1999 06:22:07 -0400 Message-ID: <5BF932D2CD05D211B54800805FE60FEB029E037E@serv-hermes.systeme.cpr.fr> From: CLAIREMBAULT Pierre Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: urgent : Zone transfer dns failed Date: Fri, 2 Jul 1999 12:06:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 In fact the file is empty because it is locked by system_1 (sub-process = of system) and even if the transfer works sucessfully, the file is not = closed. Is it a bug? Pierre -----Message d'origine----- De: CLAIREMBAULT Pierre=20 Date: jeudi 1 juillet 1999 14:34 =C0: 'Info-TCPware@process.com' Objet: RE: urgent : Zone transfer dns failed There was something wrong in the name dbsecond_123_2_10.rev (I had only = one dot). However, I have changed the name in test.rev. Now, I have no error in nameserver.log but my file test.rev is empty!=20 I have tried with another zone zzz.cpr.fr and the transfer gives an = empty file too. Another idea? Regards, Pierre -----Message d'origine----- De: Jeff Schreiber [mailto:schreiber@process.com] Date: jeudi 1 juillet 1999 14:04 =C0: Info-TCPware@process.com Cc: schreiber@process.com Objet: RE: urgent : Zone transfer dns failed CLAIREMBAULT Pierre writes: > >>And $ Exit 2320 =3D3D %SYSTEM-W-NOSUCHFILE, no such file. >> >>The file is present on the primary dns server. When I try with a = Solaris >>bind 4 secondary, the transfer zone is OK. >> >secondary 123.2.10.in-addr.arpa 10.15.127.6 = dbsecond_123_2.10.rev When the nameserver transferred the zone it creates a temporary = file, then it renames that temporary file to the backup file. Somewhere along the line it failed... the reason being because of = the file name. Please change to dbsecond_123_2_10.rev from dbsecond_123_2.10.rev = and see if you still have a problem. (VMS only allows 1 dot) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 2 Jul 1999 08:36:29 -0400 Date: Fri, 02 Jul 1999 08:25:06 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V533P040 To: TCPware-Announce@PROCESS.COM Message-ID: <01JD2Z735H9E000D9J@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V533P040 Description: Fix Rservice hang Release date: 2-JUL-1999 Versions: 5.3-3,5.3-2 ftp://ftp.process.com/support/53_3/drivers_v533p040.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- DRIVERS patch kit for TCPware Version 5.3-3 June 30, 199= 9 Copyright =A9 1999 Process Software Corporation This patch kit provides new versions of the following driver(s): BGDRIVER INETDRIVER IPDRIVER NTDRIVER TCPDRIVER The following changes have been made: BGDRIVER - D/E 2298 - Modify behaviour of IO$_DEACCESS - D/E 3509 - Modified to allow DCL/Perl scripts to= work properly under the Netscape FastTrack= web server. INETDRIVER - D/E 339 - Correct the output of an extra f= or output from REXEC IPDRIVER - D/E 2213 - Fix routine which derives largest MTU= of all physical interfaces. This is us= ed by TCP to set the MSS advertised at conn= ection establishment. - D/E 2453 - EWA twisted pair Ethernet controllers= with the cable removed would hang TCPware = during startup. This problem has been corre= cted. NTDRIVER - DE 3330: Drop any received data when closing. DE 1537: Permanent NTA /w CLOSE_DASSGN cannot b= e deleted. TCPDRIVER - D/E 3872 - Recognize SYN packets in successive connections when old connection is in TIME_WAIT (RLOGIN clients no longer h= ang on successive connections) NOTE: You must reboot your system after installing this patch in or= der to load the new driver(s). The old versions of the driver(s) will be renamed to *.EXE_OLD. Once installed, you may undo this patch by renaming the file(s) bac= k to: TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE [End of ECO announcement] ================================================================================ Archive-Date: Fri, 2 Jul 1999 10:17:33 -0400 Subject: RE: Purveyor Query Message-ID: <1999Jul2.095218@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 2 Jul 99 09:52:18 -0400 To: Info-TCPware@PROCESS.COM Derek: That is exactly how it works. First request has no authentication, so 401 is returned to browser. Browser queries for username/password and re-requests page. If 401 is again returned, browser repeats query (in case user mis-typed information, etc). I don't understand exactly what you wish to do. But, let me quess? If user entered authentication information but it is incorrect, you want to put up some kind of message page. Whereas, if the user hasn't entered any authentication, you want to allow the authentication to occur? While I don't recall what all is possible with the new feature of allowing you to "control" the error processing, I think you might be able to do this as follows: - Set up the 401 error to run a CGI script. - The CGI script will get the various CGI environment variables (WWW_*). - You can check these to see if the user entered a username (if WWW_REMOTE_USER is not an empty string) or whether the user was authenticated (check WWW_AUTH_TYPE). I'm not sure exactly what happens with these if the auth information entered is invalid. - Depending on what the values indicate, return 401 or a page. Note: If you CANCEL the authentication prompt in the browser, usually it will display whatever text was returned with the 401 status. - Bernie In article , Derek Fage writes: > Hmmm, > > Having turned on tracing and examined the worker log files, it would appear > that what happens is that the when a connection is received that has no > authentication, the worker will respond with a 401 error. It would seem that > the browser will then prompt for the username / password combination for the > realm and try again (three times) before displaying the error. > > I can see how this could create a problem for the worker process in that it > would need to keep a count of failed connection attempts so that it can send > back a 401 to force the browser to prompt the user for username / password > pairs prior to sending performing a redirection to another page. > > Can you think of any way of working around this (sounds a bit tricky) ? > > Cheers, > > Derek... > >> -----Original Message----- >> From: Derek Fage [SMTP:DerekF@itexjsy.com] >> Sent: 01 July 1999 15:36 >> To: 'Info-TCPware@process.com' >> Subject: RE: Purveyor Query >> >> Bernie, >> >> I do not understand how to do that. The authentication is done by the >> server, not the CGI. We have CGI programs and folders with HTML docs as >> well >> as zip files etc... that need to be protected, so we run a modified >> version >> of FILE_AUTH.C authentication DLL that you provide in the samples/dll >> directory. >> >> I can only presume that this is buried in the Purveyor server code itself >> somewhere to make the call to the authentication DLL and interpret the >> response to decide whether to procede or to return a 401 error. What I >> really do not understand is why when I put the new key entry in that I >> never >> even get prompted for a username password. >> >> Is there no way of getting around this ? >> >> Cheers, >> >> Derek (hopeful.........) >> >> > -----Original Message----- >> > From: volz@process.com [SMTP:volz@process.com] >> > Sent: 01 July 1999 14:19 >> > To: Info-TCPware@PROCESS.COM >> > Subject: RE: Purveyor Query >> > >> > To do the 401 page, you really need to use a CGI that returns the 401 >> > status to the browser. If you redirect it to a document, it will send >> > the document that is a 200 reply, not a 401 reply. >> > >> > So, set up a simple CGI that sends a "Status: 401" to indicate that that >> > is the status (not the 200). Then, you can send text that gives the >> > error you want (though a browser may not display it because the 401 >> > status says to ask for authentication). >> > >> > If it doesn't do what you want, then don't redirect the 401 entry. >> > >> > >> > In article , Derek Fage >> > writes: >> > > Thanks Bernie. >> > > >> > > It's the 401 error that I am particularly interested in. >> > > >> > > I setup the new key entry and restarted the server, but now >> > autentication is >> > > never performed (whenever I try to access a page that requires >> > > authentication, instead of getting prompted for a username and >> password >> > 3 >> > > times prior to displaying the original error I get redirected straight >> > to my >> > > new 401error.html page.) >> > > >> > > We use an external DLL for authentication (as we authenticate against >> > UAF >> > > for users and groups/identifiers). >> > > >> > > Any ideas ? >> > > >> > > Cheers, >> > > >> > > Derek... >> > > >> > > PS - Sorry for the long response - I've just returned from vacation. >> > > >> > > >> > >> -----Original Message----- >> > >> From: volz@process.com [SMTP:volz@process.com] >> > >> Sent: 21 June 1999 19:30 >> > >> To: Info-TCPware@PROCESS.COM >> > >> Subject: Re: Purveyor Query >> > >> >> > >> In article , Derek >> Fage >> > >> writes: >> > >> > Hi there, >> > >> > >> > >> > I'd like to find out if it is possible to modify my Purveyor >> > Wenserver >> > >> (2.0) >> > >> > so that when user authentication fails I can redirect the server to >> > >> another >> > >> > page instead of displaying the standard "Unauthorized -- >> > authentication >> > >> > failed. HTTP status code: 401" message. >> > >> > >> > >> > Regards, >> > >> > >> > >> > Derek... >> > >> >> > >> *** WARNING !!! >> > >> >> > >> The following information is being provided "as is" for Purveyor for >> > >> OpenVMS Version 2.0 and later. No support is given for these >> features. >> > >> If these features are used and you have a problem with Purveyor, >> > disable >> > >> use of these features and retest before reporting the problem. >> > >> >> > >> These features are undocumented and unsupported. >> > >> >> > >> >> > ------------------------------------------------------------------------ >> > >> >> > >> Purveyor now supports error processing documents. Instead of >> returning >> > >> the fixed (internal) error, Purveyor can instead return a customized >> > >> message. Basiscally, Purveyor "redirects" to the error document, if >> > >> configured. This document may be a .HTML, .HTP, or other file or CGI. >> > >> The document that is specified must be GLOBALLY accessible by all >> > >> virtual servers for that database configuration. If you use a file of >> > >> /error/404error.html (for example), then there must be an error >> > >> directory in each virtual servers default data directory! (Or, a >> > virtual >> > >> path of "error" configured.) >> > >> >> > >> If the indicated document can not be found or accessed, that error is >> > >> returned to the user (ie, recursion on error handling is not >> allowed). >> > >> >> > >> The log file will always log the ORIGINAL status. >> > >> >> > >> NOTICE: This is *NOT* documented and this support can NOT be >> configured >> > >> via RSM. This support hasn't been throughly tested and there may be >> > >> problems in using it. >> > >> >> > >> WARNING: Do not use a DLL that requests deferred processing! This is >> > not >> > >> supported and will cause severe problems (probably ACCVIOs). >> > >> >> > >> NOTICE: If a CGI or DLL is run, it can get the original document URL >> > >> from the WWW_REQUEST_LINE environment variable. No error code is >> passed >> > >> to it (that can be solved by having a separate CGI/DLL for each error >> > >> code). >> > >> >> > >> The key under which these entries are stored is: >> > >> SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments >> > >> >> > >> And, the values under this key are as follows: >> > >> >> > >> Value xx >> > >> Name: 404 >> > >> Type: REG_SZ >> > >> Data: /~error/notfound.html >> > >> >> > >> where Name is the error code and Data is the new URL (use of a >> virtual >> > >> path is recommended especially when using the virtual server >> support). >> > >> >> > >> You can set these entries up as follows: >> > >> >> > >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch >> > >> $ UTILITY UPDATE database - >> > >> >> > "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters\ErrorDocuments" - >> > >> "error-code" "error-URL" "REG_SZ" >> > >> >> > >> where arch is either VAX or AXP and database is the configuration >> > >> database file's name. Note that the quotes, where shown above, are >> > >> required. >> > >> >> > >> >> > ------------------------------------------------------------------------ >> > >> >> > >> Three special parameters are now supported in the configuration >> > database. >> > >> Please note that NO configuration (RSM) is provided for these >> > parameters >> > >> and they should not normally be needed. However, in some special >> > >> circumstances, there may be a reason to tune them. >> > >> >> > >> To tune these values, one must manually add them (using a text >> editor) >> > >> to the configuration database file. >> > >> >> > >> You can also add these using the following sequence: >> > >> >> > >> $ UTILITY :== $PURVEYOR:PURVEYOR_UTILITY_arch >> > >> $ UTILITY UPDATE database - >> > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - >> > >> "SO_BACKLOG" 256 "REG_DWORD" >> > >> $ UTILITY UPDATE database - >> > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - >> > >> "SO_SNDBUF" 16384 "REG_DWORD" >> > >> $ UTILITY UPDATE database - >> > >> "SYSTEM\CurrentControlSet\Services\Purveyor\Parameters" - >> > >> "SO_RCVBUF" 16384 "REG_DWORD" >> > >> >> > >> where arch is either VAX or AXP and database is the configuration >> > >> database file's name. Note that the quotes, where shown above, are >> > >> required. >> > >> >> > >> They are SYSTEM\CurrentControlSet\Services\Purveyor\Parameters: >> > >> >> > >> Value xx >> > >> Name: SO_BACKLOG >> > >> Type: REG_DWORD >> > >> Data: 256 >> > >> >> > >> Value xx+1 >> > >> Name: SO_SNDBUF >> > >> Type: REG_DWORD >> > >> Data: 16384 >> > >> >> > >> Value xx+2 >> > >> Name: SO_RCVBUF >> > >> Type: REG_DWORD >> > >> Data: 16384 >> > >> >> > >> >> > >> SO_BACKLOG allows one to set the connection backlog limit. This >> values >> > >> is passed to the TCP/IP implementation to set the connection backlog. >> > By >> > >> default, Purveyor uses 256. >> > >> >> > >> SO_SNDBUF and SO_RCVBUF allows one to set the socket send and receive >> > >> buffer limits (see setsockopt, SO_SNDBUF and SO_RCVBUF for complete >> > >> details). By default, Purveyor uses 16384 for each of these. >> > >> >> > >> >> > >> Reasons for wanting to tune these values could include: >> > >> >> > >> SO_BACKLOG >> > >> If a TCP/IP implementation does not allow (and does not >> > >> silently ignore) a value larger than its backlog limit. >> > >> >> > >> SO_SNDBUF/SO_RCVBUF >> > >> To reduce the potential buffer space needed on a system for >> > >> HTTP connections. With the 16384 default, having lots of slow >> > >> or hung connections can result in significant buffer usage. >> > >> Reducing these values can help avoid this at a decrease in >> > >> network throughput. This is especially a consideration for >> > >> TCP/IP Services for OpenVMS. ================================================================================ Archive-Date: Tue, 6 Jul 1999 11:17:53 -0400 From: "IT Help required" Reply-To: Info-TCPware@process.com Subject: Dual IP'ing - info on doing Date: 6 Jul 1999 15:05:26 GMT Message-ID: <01bec7c0$c3254340$8cebe0c3@test> To: Info-TCPware@PROCESS.COM I'm seeking information on how to have dual IP's on a single physical adapter. These IP will be different subnets Current 128.1.199.2 255.255.255.0 Additional required 172.16.20.2 255.255.255.0 The system is Vac 4105a, running VMS 6.2, TCPWare Ver 5.3 Any help/procedures for doing much appreciated. Regards Paul ================================================================================ Archive-Date: Tue, 6 Jul 1999 11:36:17 -0400 Date: Tue, 6 Jul 1999 16:27:18 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: Re: Dual IP'ing - info on doing In-Reply-To: <01bec7c0$c3254340$8cebe0c3@test> To: IT Help required , Info-TCPware Message-ID: <99Jul6.163552bst.17928@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/PLAIN In your ROUTING.COM file $ NETCU ADD SECONDARY ip_address /Steve ================================================================================ Archive-Date: Tue, 6 Jul 1999 11:57:06 -0400 Sender: bryant@process.com Date: Tue, 6 Jul 1999 11:53:52 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009DAB2E.AE564968.15@process.com> Subject: RE: Dual IP'ing - info on doing "IT Help required" writes: > >I'm seeking information on how to have dual IP's on a single physical >adapter. >These IP will be different subnets >Current > 128.1.199.2 255.255.255.0 >Additional required > 172.16.20.2 255.255.255.0 > >The system is >Vac 4105a, running VMS 6.2, TCPWare Ver 5.3 > >Any help/procedures for doing much appreciated. > >Regards >Paul There are two approaches available in TCPware: - Secondary address. This allows another address and is useful if you want cluster fialover of the address. This has been in TCPware for a very long time. - Pseudo device. You can configure a pseudo-device. If you don't want cluster failover, I would recommend configuring a pseudo-device with the second address/mask and tying it to the physical adapter. Pseudo-device support came in TCPware 5.3-3. In general I would recommend the pseudo device. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 8 Jul 1999 06:14:31 -0400 Message-ID: <37847947.DCC18FC5@onsight.nl> Date: Thu, 08 Jul 1999 12:11:19 +0200 From: "Marcel Knippen" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware Subject: Strange FTP Behaviour Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 2x AlphaServer 1000A, VMS 7.1, TCPware 5.3-2 in a cluster on a switched Ethernet network. FTP Session from a PC in same subnet. FTP Sessions of 30MB+ files from a PC to one of the systems corrupt files with only 1 bit. Everytime at different location(s) within the file a byte xxxxx0xx is replaced by xxxxx1xx. No problems with same FTP session to other AlphaServer. Questions: 1. With all the checksums on Ethernet, IP and TCP level, can it be possible to have a corruption of 1 bit ? 2. Does someone have a hint how to solve this ? Regards, Marcel Knippen Onsight Solutions ================================================================================ Archive-Date: Thu, 8 Jul 1999 11:41:13 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE869038E3@lespaul.process.com> From: Mike Duffy Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Strange FTP Behaviour Date: Thu, 8 Jul 1999 11:37:45 -0400 MIME-Version: 1.0 Content-Type: text/plain Single-bit errors should be caught by just about every scheme you can imagine, so it would be unlikely to be a failure on that level. You might capture the network traffic and make sure whether the data are coming in already corrupted or not. (I realize that would be quite a large dump file, and tedious). This is kind of a long shot, but... Last time I saw something like that, it was a problem completely external to the software exhibiting the problem. The problem was a totally unrelated piece of software writing into pool shortly AFTER releasing the packet containing the bit in question. After the pool packet had been allocated by the next guy the original program performed a BICx, thereby clearing one bit which belonged to the new guy. If the bit was already clear, nobody noticed. On VAX, nobody noticed because the recently released pool did not come up again until after the error had occured. On Alpha, the opposite was true, as released packets go to the front of the list. If your problem is something similar, I might expect to see a longword alignment rather than byte alignment. Mike Duffy Process Software Corp. (but not a member the FTP group) -----Original Message----- From: Marcel Knippen [mailto:Marcel.Knippen@onsight.nl] Sent: Thursday, July 08, 1999 6:11 AM To: Info-TCPware Subject: Strange FTP Behaviour 2x AlphaServer 1000A, VMS 7.1, TCPware 5.3-2 in a cluster on a switched Ethernet network. FTP Session from a PC in same subnet. FTP Sessions of 30MB+ files from a PC to one of the systems corrupt files with only 1 bit. Everytime at different location(s) within the file a byte xxxxx0xx is replaced by xxxxx1xx. No problems with same FTP session to other AlphaServer. Questions: 1. With all the checksums on Ethernet, IP and TCP level, can it be possible to have a corruption of 1 bit ? 2. Does someone have a hint how to solve this ? Regards, Marcel Knippen Onsight Solutions ================================================================================ Archive-Date: Thu, 8 Jul 1999 11:52:29 -0400 Message-ID: <4.1.19990708094620.00c6b760@mehlhop.org> Date: Thu, 08 Jul 1999 09:47:38 -0600 X-MX-Warning: Warning -- Invalid "To" header. To: Info-TCPware@process.com, From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: RE: Strange FTP Behaviour In-Reply-To: <63D30D6E10CFD11190A90000F805FE869038E3@lespaul.process.com > MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:37 AM 7/8/99 -0400, Mike Duffy wrote: >Single-bit errors should be caught by just about every >scheme you can imagine, so it would be unlikely to be a >failure on that level. You might capture the network >traffic and make sure whether the data are coming in already >corrupted or not. (I realize that would be quite a >large dump file, and tedious). > >This is kind of a long shot, but... > >Last time I saw something like that, it was a problem completely >external to the software exhibiting the problem. > >The problem was a totally unrelated piece of software >writing into pool shortly AFTER releasing the packet >containing the bit in question. > >After the pool packet had been allocated by the next guy >the original program performed a BICx, thereby clearing one bit >which belonged to the new guy. If the bit was already clear, >nobody noticed. > >On VAX, nobody noticed because the recently released pool did >not come up again until after the error had occured. >On Alpha, the opposite was true, as released packets go to the >front of the list. > >If your problem is something similar, I might expect to see >a longword alignment rather than byte alignment. If that is the case you may want to turn poolchecking on with a poison pattern that has that bit position clear. Jim > >Mike Duffy >Process Software Corp. >(but not a member the FTP group) > >-----Original Message----- >From: Marcel Knippen [mailto:Marcel.Knippen@onsight.nl] >Sent: Thursday, July 08, 1999 6:11 AM >To: Info-TCPware >Subject: Strange FTP Behaviour > > > >2x AlphaServer 1000A, VMS 7.1, TCPware 5.3-2 in a cluster on a >switched Ethernet network. FTP Session from a PC in same subnet. > >FTP Sessions of 30MB+ files from a PC to one of the systems >corrupt files with only 1 bit. Everytime at different location(s) >within the file a byte xxxxx0xx is replaced by xxxxx1xx. > >No problems with same FTP session to other AlphaServer. > >Questions: >1. With all the checksums on Ethernet, IP and TCP level, can it > be possible to have a corruption of 1 bit ? >2. Does someone have a hint how to solve this ? > >Regards, > > >Marcel Knippen >Onsight Solutions _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Fri, 9 Jul 1999 09:55:01 -0400 From: "Kenneth Randell" Reply-To: Info-TCPware@process.com Subject: Re: Strange FTP Behaviour Date: Fri, 9 Jul 1999 09:49:36 -0400 Message-ID: <7m4uni$nfr$1@autumn.news.rcn.net> To: Info-TCPware@PROCESS.COM Um...are you postive your hardware is all in working order??? I say this because once I had a Microvax II with a DELQA go bad, resulting in corrupted file transfers, missing/bad characters in telnet (with one bit in particular that was missing or corrupted) and DECNET SET HOST sessions, but there were absolutely no device errors logged by the VMS System or DECNET during this whole time. I had run out of ideas, so I had the hardware guy come in and replace the board, and viola, problem disappeared. Ken Randell Marcel Knippen wrote in message <37847947.DCC18FC5@onsight.nl>... > >2x AlphaServer 1000A, VMS 7.1, TCPware 5.3-2 in a cluster on a >switched Ethernet network. FTP Session from a PC in same subnet. > >FTP Sessions of 30MB+ files from a PC to one of the systems >corrupt files with only 1 bit. Everytime at different location(s) >within the file a byte xxxxx0xx is replaced by xxxxx1xx. > >No problems with same FTP session to other AlphaServer. > >Questions: >1. With all the checksums on Ethernet, IP and TCP level, can it > be possible to have a corruption of 1 bit ? >2. Does someone have a hint how to solve this ? > >Regards, > > >Marcel Knippen >Onsight Solutions ================================================================================ Archive-Date: Wed, 14 Jul 1999 15:17:14 -0400 From: "Joe Gray" Reply-To: Info-TCPware@process.com To: Subject: any ideas? Date: Wed, 14 Jul 1999 14:13:25 -0500 Message-ID: <000001bece2c$f4481480$633f366a@graypc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit WE have TCPware and several Emulex 4000 terminal servers. Administering the terminal servers via Decnet from OpenVms works fine and printing via TSSYM also works fine. My current problem is that the servers need to move behind routers that do not pass LAT and therefore I need to administer via TFTP. It seems both the Emulex and TCPware have TFTP but how does one get them together? Thanx for any ideas. jgray@sparksco.com ================================================================================ Archive-Date: Thu, 15 Jul 1999 11:43:01 -0400 Date: Thu, 15 Jul 1999 11:31:04 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: POP3_V533P022 To: TCPware-Announce@PROCESS.COM Message-ID: <01JDLBH5FAOY000S7C@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: POP3_V533P022 Description: Assorted POP3 fixes Release date: 15-JUL-1999 Versions: 5.3-3,5.3-2,5.2-3,5.1-5,5.1-4,5.0-4 ftp://ftp.process.com/support/53_3/pop3_v533p022.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ----------------------------------------------------------------------- POP3 Patch kit (revision 2.2) for TCPware version 5.3-3 16-Jun-1999 Copyright (c) 1999, by Process Software Corporation This kit replaces the POP3 Patch Kit revision 2.1, and corrects all problems corrected in revsion 2.1 of the patch. This VMSinstallable saveset provides a new version of POP3 for TCPware for OpenVMS. POP3 must be shut down before installing. You must restart the component after installation. This patch is applicable to TCPware 5.0-4 or higher on all the supported version of OpenVMS VAX and OpenVMS Alpha. The following problems have been corrected in this patch: 1. Very long messages would sometimes cause a POP3 server ACCVIO, or would cause the POP3 client to hang. 2. If the VMS mail file that contains a mail message was missing, the POP3 client could hang. The old version of POP3D.EXE will be renamed to TCPWARE_COMMON:[TCPWARE]POP3D.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE_COMMON:[TCPWARE]POP3D.EXE and restarting POP3 component. ----------------------------------------------------------------------- POP3 Patch kit (revision 2.1) for TCPware version 5.3-3 06-Apr-1999 Copyright (c) 1999, by Process Software Corporation This kit replaces the POP3 Patch Kit revision 2.0, and corrects all problems corrected in revsion 2.0 of the patch. This VMSinstallable saveset provides a new version of POP3 for TCPware for OpenVMS. POP3 must be shut down before installing. You must restart the component after installation. This patch is applicable to TCPware 5.0-4 or higher on all the supported version of OpenVMS VAX and OpenVMS Alpha. The following problems have been corrected in this patch: 1. Messages delivered via SMTP would not download properly, causing most POP3 clients to hang. The old version of POP3D.EXE will be renamed to TCPWARE_COMMON:[TCPWARE]POP3D.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE_COMMON:[TCPWARE]POP3D.EXE and restarting POP3 component. ----------------------------------------------------------------------- POP3 Patch kit (revision 2.0) for TCPware version 5.3-3 04-Mar-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of POP3 for TCPware for OpenVMS. POP3 must be shut down before installing. You must restart the component after installation. This patch is applicable to TCPware 5.0-4 or higher on all the supported version of OpenVMS VAX and OpenVMS Alpha. The following problems have been corrected in this patch: 1. The message size calculated for each message could have been very incorrect for smaller messages. 2. The number of octets calculated for the segment of the message displayed as a result of a TOP command would be incorrect. 3. The TOP command worked correctly only for messages created by and sent to VMSmail accounts. For messages delivered to the VMS server via rfc822-compatible agents, the TOP command returned incorrect amounts of data. The old version of componentname will be renamed to TCPWARE_COMMON:[TCPWARE]POP3D.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE_COMMON:[TCPWARE]POP3D.EXE and restarting POP3 component. ----------------------------------------------------------------------- POP3 Patch kit (revision 1.0) for TCPware version 5.3-3 21-Jul-1998 Copyright (c) 1998, by Process Software Corporation This VMSinstallable saveset provides a new version of POP3 for TCPware for OpenVMS. POP3 must be shut down before installing, you must restart the component after installation. This patch is applicable to TCPware 5.0-4 or higher on all the supported version of VAX/VMS and OpenVMS. The following change has been made: 1. POP3 server now deny access to expired account. This feature can be disabled by the logical: $ DEFINE/SYSTEM/EXEC TCPWARE_POP3_ALLOW_EXPIRED "TRUE" [End of ECO announcement] ================================================================================ Archive-Date: Wed, 21 Jul 1999 07:17:54 -0400 From: Tony Sanger Reply-To: Info-TCPware@process.com Subject: NFS - Slow reading large directories Date: Wed, 21 Jul 1999 10:56:29 GMT Message-ID: <7n490q$ove$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM We have performance problems serving directories with over 2921 files in them. Some NFS clients are able to handle the large delays experienced, but the users complain. This behavior is seen from a variety of clients, TCPware on Vax/Alpha, Sun Unix, DOS, WIN95/98/NT, and Novell. When a DIR command is issued the files are returned in bursts with delays of about a minute between each burst. I have yet to caluculate/trace number of files returned in each burst. The directory concerned can have up to 6000 added to it on a daily basis, it is cleared down every day. Any clues/hits on how to solve this problem ? Regards Tony Sanger Time taken to list files on a TCPware NFS volume served from a TCPware server. Directory NFS3:[NFS-TEST] No: of Files Time taken for DIR/TOT 2850 00:00:04.98 2900 00:00:05.06 2905 00:00:12.72 2910 00:00:10.06 2915 00:00:05.06 2920 00:00:13.51 2921 00:00:05.37 2921 00:00:07.08 2921 00:00:05.13 2922 00:01:50.18 2922 00:01:22.02 2922 00:01:10.96 2923 00:01:22.39 2924 00:01:21.87 2925 00:02:33.60 2925 00:01:24.08 2950 00:02:41.37 2960 00:02:41.99 2980 00:03:57.55 2985 00:03:01.16 2985 00:02:36.81 2989 00:02:17.33 3000 00:02:56.71 3000 00:02:23.31 6000 00:09:57.53 $! *** NFS-OpenVMS Server parameters *** $ NFS_SERVER == 1 $ NFS_ACCESS_IDENTIFIER == "" $ NFS_SECURITY == 0 $ NFS_LOG_CLASS == -1 $ NFS_PCNFSD_ENABLE == 1 $ NFS_PCNFSD_SPOOL == "" $ NFS_PCNFSD_PRINTER == "" $ NFS_PCNFSD_DFLTPRTOPT == "" $ NFS_PCNFSD_JOB_LIMIT == "" $ NFS_PCNFSD_PRINTER_LIMIT == "" $ NFS_NOCHECKSUM == 1 $ NFS_UDP_THREADS == 800 $ NFS_TCP_THREADS == 500 $ NFS_XID_CACHE_SIZE == 10000 $ NFS_DIRTIME_TIMER == "0 00:00:30.00" $ NFS_DIRLIFE_TIMER == "0 00:10:00.00" $ NFS_OPENFILE_TIMER == "0 00:00:06.00" $ NFS_FILE_CACHE_SIZE == 30000 $ NFS_DIRREAD_LIMIT == 0 $ NFS_PORT == 2049 $ NFS_DFLT_UID == -2 $ NFS_DFLT_GID == -2 $ NFS_OPTIONS == 0 Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ================================================================================ Archive-Date: Wed, 21 Jul 1999 10:45:03 -0400 Message-ID: <4.1.19990721083551.00c6a8e0@mehlhop.org> Date: Wed, 21 Jul 1999 08:39:31 -0600 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: NFS - Slow reading large directories In-Reply-To: <7n490q$ove$1@nnrp1.deja.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" This is more likely a VMS limitation. VMS does not cache directory information on Dir files bigger than 127 blocks. Performance in those cases is EXTREMELY impacted. To tell if that is your problem. $ Set def 'dir with problem' $ dir/siz=all [-]'directory name' if EITHER number is greater than 127 this is most likely your problem. Jim At 10:56 AM 7/21/99 +0000, you wrote: >We have performance problems serving directories with over 2921 files in >them. Some NFS clients are able to handle the large delays experienced, >but the users complain. This behavior is seen from a variety of >clients, TCPware on Vax/Alpha, Sun Unix, DOS, WIN95/98/NT, and Novell. > >When a DIR command is issued the files are returned in bursts with >delays of about a minute between each burst. I have yet to >caluculate/trace number of files returned in each burst. > > >The directory concerned can have up to 6000 added to it on a daily >basis, it is cleared down every day. > >Any clues/hits on how to solve this problem ? > >Regards > > >Tony Sanger > > >Time taken to list files on a TCPware NFS volume served from a TCPware >server. > >Directory NFS3:[NFS-TEST] >No: of Files Time taken for DIR/TOT >2850 00:00:04.98 >2900 00:00:05.06 >2905 00:00:12.72 >2910 00:00:10.06 >2915 00:00:05.06 >2920 00:00:13.51 >2921 00:00:05.37 >2921 00:00:07.08 >2921 00:00:05.13 > >2922 00:01:50.18 >2922 00:01:22.02 >2922 00:01:10.96 >2923 00:01:22.39 >2924 00:01:21.87 >2925 00:02:33.60 >2925 00:01:24.08 >2950 00:02:41.37 >2960 00:02:41.99 >2980 00:03:57.55 >2985 00:03:01.16 >2985 00:02:36.81 >2989 00:02:17.33 >3000 00:02:56.71 >3000 00:02:23.31 >6000 00:09:57.53 > > >$! *** NFS-OpenVMS Server parameters *** >$ NFS_SERVER == 1 >$ NFS_ACCESS_IDENTIFIER == "" >$ NFS_SECURITY == 0 >$ NFS_LOG_CLASS == -1 >$ NFS_PCNFSD_ENABLE == 1 >$ NFS_PCNFSD_SPOOL == "" >$ NFS_PCNFSD_PRINTER == "" >$ NFS_PCNFSD_DFLTPRTOPT == "" >$ NFS_PCNFSD_JOB_LIMIT == "" >$ NFS_PCNFSD_PRINTER_LIMIT == "" >$ NFS_NOCHECKSUM == 1 >$ NFS_UDP_THREADS == 800 >$ NFS_TCP_THREADS == 500 >$ NFS_XID_CACHE_SIZE == 10000 >$ NFS_DIRTIME_TIMER == "0 00:00:30.00" >$ NFS_DIRLIFE_TIMER == "0 00:10:00.00" >$ NFS_OPENFILE_TIMER == "0 00:00:06.00" >$ NFS_FILE_CACHE_SIZE == 30000 >$ NFS_DIRREAD_LIMIT == 0 >$ NFS_PORT == 2049 >$ NFS_DFLT_UID == -2 >$ NFS_DFLT_GID == -2 >$ NFS_OPTIONS == 0 > > > >Sent via Deja.com http://www.deja.com/ >Share what you know. Learn what you don't. _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Thu, 22 Jul 1999 11:27:00 -0400 Message-ID: From: John Bell Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: re hosts. Date: Thu, 22 Jul 1999 16:24:25 -0000 ++++++++++++++++++++++++++++++++++++++++++++++++++ Please read the disclaimer at the bottom of this e-mail. ++++++++++++++++++++++++++++++++++++++++++++++++++ Does any one know if there is a limit to the number of entries in tcpware:hosts. Regards John ---------------------------------------------------- Please note: This e-mail is intended for the named recipient(s) only. Its contents are confidential and may only be retained by the named recipient(s) and may only be copied or disclosed with the consent of The London Clearing House (LCH). If you are not an intended recipient please delete this e-mail and notify postmaster@lch.co.uk. The contents of this e-mail are subject to contract in all cases, and LCH makes no contractual commitment save where confirmed by hard copy. LCH accepts no liability, including liability for negligence, in respect of any statement in this e-mail. The London Clearing House Limited, Registered Office: Aldgate House, 33 Aldgate High Street, London EC3N 1EA. Registered in England No. 25932 Recognised as a Clearing House under the Financial Services Act 1986. Telephone: 0171 426 7000 Internet: http://www.lch.co.uk ---------------------------------------------------- ================================================================================ Archive-Date: Thu, 22 Jul 1999 19:06:40 -0400 Subject: Re: re hosts. Message-ID: <1999Jul22.184016@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 22 Jul 99 18:40:16 -0400 To: Info-TCPware@PROCESS.COM In article , John Bell writes: > Does any one know if there is a limit to the number of entries in > tcpware:hosts. > > Regards John There isn't any limit. Though the more entries you have, the longer it will take to scan it when a user attempts to log in. The file is read from beginning to end - it isn't loaded into a static table or some such limiting thing. - Bernie Volz Process Software ================================================================================ Archive-Date: Fri, 23 Jul 1999 11:14:22 -0400 Subject: Re: re hosts. Message-ID: <1999Jul23.102226@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 23 Jul 99 10:22:26 -0400 To: Info-TCPware@PROCESS.COM Sorry ... I answered the question incorrectly. I thought you had asked about the .rhosts file and not the hosts. file. The .rhosts file is unlimited as indicated in my initial reply. For the hosts. file, there isn't any fixed limit it just depends on how much VM is available to the TCPware_DNS process. The data is loaded into memory when the TCPware_DNS process starts (or when it detects the file has changed). In general, we do NOT recommend you put lots of entries into the hosts. file - use the Domain Name Services instead. DNS is far superior to maintain a large hosts. file. - Bernie Volz Process Software In article <1999Jul22.184016@alcor.process.com>, volz@process.com (Bernie Volz) writes: > In article , John Bell writes: >> Does any one know if there is a limit to the number of entries in >> tcpware:hosts. >> >> Regards John > > There isn't any limit. Though the more entries you have, the longer it > will take to scan it when a user attempts to log in. > > The file is read from beginning to end - it isn't loaded into a static > table or some such limiting thing. > > - Bernie Volz > Process Software