Archive-Date: Thu, 6 Feb 2003 17:55:19 -0400 Date: Thu, 6 Feb 2003 17:55:01 -0400 From: goathunter@PROCESS.COM Reply-To: Info-TCPware@process.com To: TCPware-Announce@PROCESS.COM Message-ID: <00A1B191.5594F329.11@triton.process.com> Subject: TCPware ECO kit available: DRIVERS_V562P020 TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V562P020 Description: Fix for system crash in 64-bit environments Release date: 6-FEB-2003 Ranking: 0 for AXP Ranking: 3 for VAX Max ranking: 0 Versions: 5.6-2 ftp://ftp.process.com/support/56_2/drivers_v562p020.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 revision 2.0 for TCPware Version 5.6-2 05-Feb-2003 Copyright (c) 2002-2003 Process Software, LLC Highest ECO Rank 0 (Version 2.0) Version 2.0 Rank 0 - Mandatory for AXP systems This patch kit provides new versions of the following drivers for TCPware Version 5.6-2: DRIVERS_V562P020 - ECO rank: 0 - Mandatory for AXP V7 systems ------------------ BGDRIVER - A defect was present in an error path that would cause a system crash in 64-bit environments. (D/E 8746) This kit also includes the following changes from previous ECO kits: DRIVERS_V562P010 - ECO rank: 3 ------------------ UCX$IPC_SHR - BSD 4.4 entry points have been added for OpenVMS Alpha V7.1 and later. This allows code compiled for these entry points to run. An example is Mozilla. (D/E 8245) NOTE: You must reboot your system after installing this patch in order 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) back to: TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE [End of ECO announcement] ================================================================================ Archive-Date: Thu, 6 Feb 2003 18:14:25 -0400 Date: Thu, 6 Feb 2003 18:14:05 -0400 From: goathunter@PROCESS.COM Reply-To: Info-TCPware@process.com To: TCPware-Announce@PROCESS.COM Message-ID: <00A1B193.FFC41A30.3@triton.process.com> Subject: TCPware ECO kit available: DRIVERS_V553P050 TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V553P050 Description: Fix for system crash in 64-bit environments. Release date: 6-FEB-2003 Ranking: 0 for AXP with DRIVERS_V553P023 Ranking: 3 for VAX Max ranking: 0 Versions: 5.5-3,5.4-3 ftp://ftp.process.com/support/55_3/drivers_v553p050.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 revision 5.0 for TCPware Version 5.5-3 05-Feb-2003 Copyright (c) 1999-2000 Process Software Corporation Copyright (c) 2000-2003 Process Software, LLC Highest ECO Rank 0 (Version 5.0) Version 5.0 Rank 0 - Mandatory upgrade of DRIVERS_V553P023 for AXP This patch kit provides new versions of the following drivers for TCPware Version 5.5-3: DRIVERS_V553P041 - ECO rank: 0 - Mandatory for AXP systems running DRIVERS_V553P023 or later. ------------------ BGDRIVER - defect was present in an error path that would cause a system crash in 64-bit environments. (D/E 8746) NOTE: You must reboot your system after installing this patch in order to load the new driver(s). This kit also includes the following changes from previous ECO kits: For TCPware V5.5-3: DRIVERS_V553P041 - ECO rank: 3 ------------------ TCPDRIVER - Fixes a problem with selects coming from BGDRIVER where if two processes access a BG device with an outstanding select, the select might hang. This can cause Apache (CSWS) to hang. (D/E 6991) PWIPDRIVER - Sets TCP_NODELAY on some TCP connections which were not set in eco DRIVERS_V553P032. This provides for increased performance. UCX$IPC_SHR - BSD 4.4 entry points have been added. This allows code compiled for these entry points to run. An example is Mozilla. Note that this is to support DEC C RTL routines supplied with VMS V7.x on Alpha systems only (D/E 8245) DRIVERS_V553P040 - ECO rank: 2 ------------------ PWIPDRIVER - Shutting down TCPware while Pathworks applications are active had the potential to cause a system crash during the cleanup. (D/E 8150) DRIVERS_V553P032 - ECO rank: 1 ------------------ PWIPDRIVER - Sets TCP_NODELAY option on TCP connections to increase performance (Case 104182) - Fix crash caused by page fault at elevated IPL (D/E 5980) RMTDRIVER - Fixes a system crash when a backup application is used. (D/E 7704) TCPDRIVER - A problem in the 64-bit support that could cause a system crash in the TCPdriver has been corrected. This ECO is only necessary for AXP V7 systems that are running DRIVERS_V553P023. (D/E 8135) DRIVERS_V553P023 - ECO rank: 3 ------------------ BGDRIVER - 64-bit support added [required for to run Oracle 8.1.7 MTS] (D/E 6995) UCX$IPC_SHR - 64-bit support added (D/E 6995) TCPDRIVER - 64-bit support for BGDRIVER added (D/E 6995) UDPDRIVER - 64-bit support for BGDRIVER added (D/E 6995) IPDRIVER - 64-bit support for BGDRIVER added (D/E 6995) DRIVERS_V553P010 - ECO rank: 1 ------------------ TCPDRIVER - Fixes a system crash when a certain malformed TCP segment is received. (D/E 7271) For TCPware V5.4-3: DRIVERS_V543P051 - ECO rank: 3 ------------------ BGDRIVER - privs are no longer required for setting the TCP_NODELAY socket option. (D/E 6790) TCPDRIVER - On VMS version 7.2-1H1 a VMS problem can cause the NETCP process to go RWAST due to an outstanding direct I/O operation to a TCP device (IO$_CREATE). Changed IO$_CREATE to be a buffered I/O operation as workaraound. (D/E 6680) DRIVERS_V543P042 - ECO rank: 3 ------------------ UCX$IPC_SHR - Support for aborting a select() call was required for compatibility with Oracle Version 8.1.6. (D/E 6619) DRIVERS_V543P030 - ECO rank: 2 ------------------ IPDRIVER - On some Alphas, VMS's VCI layer does not report a device error when a cable is unplugged from the network card. This version of IPDRIVER provides a workaround, which allows the paired network interface failover support to work. (D/E 6150) DRIVERS_V543P020 ------------------ BGDRIVER - Add support for "privileged sockets" to allow beta 2 of the Apache server from Compaq to work. (D/E 5732) - Add support for the DEC C values of the multicast options to BGDRIVER (actual change was to IPDRIVER). (D/E 5733) - Under certain circumstances, code introduced in DRIVERS_V543P020 could cause an Unexpected System Service Exception and crash the system when doing NETCU SET BG_TCP commands. (D/E 6224, D/E 6243) TCPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) UDPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) IPDRIVER - Add proper VMS V7.2 privilege check. (D/E 5775) DRIVERS_V543P010 ------------------ TCPDRIVER - Changes made to the Outgoing Access Restrictions feature that corrects problems introduced in TCPware 5.4 and DRIVERS_V533P050. (D/E 5350) NOTE: You must reboot your system after installing this patch in order 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) back 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 TCPWARE_COMMON:[TCPWARE]PWIPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]PWIPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]RMTDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]RMTDRIVER.EXE TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE [End of ECO announcement] ================================================================================ Archive-Date: Tue, 11 Feb 2003 11:52:14 -0400 Date: Tue, 11 Feb 2003 11:50:20 -0500 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Note on eco kit FTP_V562P030 To: tcpware-announce@process.com Message-ID: <01KSB6VK2CU8A25B69@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Please note that when eco kit FTP_V562P030 was released, the readme neglected to mention that the following: - TCPware FTP has changed the output from an NLST command to retain the case of the filenames when not operating in Unix mode. (When operating in Unix mode the SRI encoding governs the case of the filenames.) This change allows MGETs for case-sensitive filenames to work correctly on ODS-5 disks on VMS V7.3-1 and later. The logical TCPWARE_FTP_LOWERCASE_NLST has been added to make the old behavior available. When TCPWARE_FTP_LOWERCASE_NLST is defined to True, Yes, or 1 then the file names will be set to lowercase as they have been in the past. ECO FTP_V562P030, Rank 3 (DE 8660) The kit has been updated to include the corrected readme file, but no executable images in the kit were changed. If you have already installed this eco, you do not need to re-install it. If you did not install the eco and this problem applies to you, please install the eco. Geoff Bryant Process Software ================================================================================ Archive-Date: Wed, 12 Feb 2003 13:59:40 -0400 Date: Wed, 12 Feb 2003 14:44:41 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SNMPD_V562P030 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01KSCREY4BEQ000HLQ@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: SNMPD_V562P030 Description: Assorted fixes Release date: 12-FEB-2003 Ranking: 3 Max ranking: 2 Versions: 5.6-2,5.5-3 Requisites: ftp://ftp.process.com/support/56_2/snmpd_v562p030.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. ----------------------------------------------------------- SNMPD Patch kit (revision 3.0) for TCPware version 5.6-2 7-Feb-2003 Copyright (c) 2001, 2002, 2003 by Process Software This VMSinstallable saveset provides new versions of SNMPD.EXE for TCPware for OpenVMS. TCPWare V5.5-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later You must restart SNMP after installation. The following changes have been made: Correct an error in passing the object id value that was introduced in SNMPD_V562P020 DE 8763 SNMPD_V562p030 ECO Rank: 3 (Corrects a specific problem) This patch includes the following fixes released earlier: An error which could cause the SNMP Agent to ACCVIO when setting an object id value in an Agent X subagent has been corrected. DE 8664 ECO level 2 SNMPD_V562P020 A problem with returning the full contents of Agent X octet strings has been corrected. This corrects problems with the NIC MIB of the Insight Management agents on VMS V7 on AXP. DE 8655 ECO level 3 SNMPD_V562P010 A problem with the way Agent X object Ids are returned has been corrected. DE 8363 ECO level 3 SNMPD_V562P010 After installing the patch kit you should issue the following command to cause the new image to be used: $ @tcpware:restart snmp [End of ECO announcement] ================================================================================ Archive-Date: Fri, 21 Feb 2003 09:21:12 -0400 Date: Thu, 20 Feb 2003 23:09:43 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: [TCPware V5.6-2 = BIND 8.1.2] How to get rid of error messages To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: I've a TCPware BIND server with dynamic updates allowed (to allow a NT5 to register its SRV RR itself). But it doesn't work (as expected ;-) NT does register some records but not all, because it can't. And so periodically there are a lot of OPCOMs. named: error processing update packet id 55297 from [192.168.1.16].2796 named: error processing update packet id 55809 from [192.168.1.16].2798 named: error processing update packet id 56321 from [192.168.1.16].2802 named: error processing update packet id 56833 from [192.168.1.16].2804 named: error processing update packet id 57345 from [192.168.1.16].2806 named: error processing update packet id 58625 from [192.168.1.16].2812 named: error processing update packet id 59137 from [192.168.1.16].2814 named: error processing update packet id 59649 from [192.168.1.16].2816 named: error processing update packet id 60161 from [192.168.1.16].2818 named: error processing update packet id 60673 from [192.168.1.16].2820 named: error processing update packet id 61185 from [192.168.1.16].2822 named: error processing update packet id 61697 from [192.168.1.16].2824 named: error processing update packet id 62209 from [192.168.1.16].2826 named: error processing update packet id 62721 from [192.168.1.16].2828 named: error processing update packet id 63233 from [192.168.1.16].2830 named: error processing update packet id 63745 from [192.168.1.16].2832 named: error processing update packet id 64257 from [192.168.1.16].2834 named: error processing update packet id 64769 from [192.168.1.16].2836 named: error processing update packet id 65281 from [192.168.1.16].2838 named: Sent NOTIFY for "langstoeger.at IN SOA" (langstoeger.at); 2 NS, 2 A named: approved AXFR from [192.168.1.2].1751 for "langstoeger.at" named: zone transfer of "langstoeger.at" (IN) to [192.168.1.2].1751 named: approved AXFR from [192.168.1.16].2848 for "langstoeger.at" named: zone transfer of "langstoeger.at" (IN) to [192.168.1.16].2848 Why is NT5 using DDNS update packets which TCPware doesn't understand ? Is there a way to trace them better/at-all (except a sniffer) ? Is it TCPware's or M$'s fault ? Will a BIND 9 work ? (TCPIP V5.3 has BIND 9) But to top it, NT5 is destroying the domain also: A restart (not reload) of the primary gives: named: starting. named 8.1.2 for TCPware V5.6-2 named: Process Software named: master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 1) named: master zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2003012601) named: owner name "gc._msdcs.langstoeger.at" IN (primary) is invalid - rejecting named: LANGSTOEGER_AT.DB:34: owner name error named: LANGSTOEGER_AT.DB:34: Database error (A) named: master zone "langstoeger.at" (IN) rejected due to errors (serial 2003021954) named: cache zone "" (IN) loaded (serial 0) named: listening on [192.168.1.3].53 (EWA-0) named: listening on [127.0.0.1].53 (LPB-0) named: Forwarding source address is [0.0.0.0].1233 named: Ready to answer queries. btw: a reload doesn't show this problems (but why): named: Forwarding source address is [0.0.0.0].1229 named: Ready to answer queries. It seems to only work, when you run the NT5 as primary obviously... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Fri, 21 Feb 2003 09:34:16 -0400 Date: Fri, 21 Feb 2003 09:32:17 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: [TCPware V5.6-2 = BIND 8.1.2] How to get rid of error messages To: info-tcpware@process.com Message-ID: <3E563871.7060109@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit References: Peter LANGSTOEGER wrote: > I've a TCPware BIND server with dynamic updates allowed (to allow a NT5 > to register its SRV RR itself). > > But it doesn't work (as expected ;-) > > NT does register some records but not all, because it can't. > And so periodically there are a lot of OPCOMs. > > named: error processing update packet id 55297 from [192.168.1.16].2796 > named: error processing update packet id 55809 from [192.168.1.16].2798 > named: error processing update packet id 56321 from [192.168.1.16].2802 > named: error processing update packet id 56833 from [192.168.1.16].2804 > named: error processing update packet id 57345 from [192.168.1.16].2806 > named: error processing update packet id 58625 from [192.168.1.16].2812 > named: error processing update packet id 59137 from [192.168.1.16].2814 > named: error processing update packet id 59649 from [192.168.1.16].2816 > named: error processing update packet id 60161 from [192.168.1.16].2818 > named: error processing update packet id 60673 from [192.168.1.16].2820 > named: error processing update packet id 61185 from [192.168.1.16].2822 > named: error processing update packet id 61697 from [192.168.1.16].2824 > named: error processing update packet id 62209 from [192.168.1.16].2826 > named: error processing update packet id 62721 from [192.168.1.16].2828 > named: error processing update packet id 63233 from [192.168.1.16].2830 > named: error processing update packet id 63745 from [192.168.1.16].2832 > named: error processing update packet id 64257 from [192.168.1.16].2834 > named: error processing update packet id 64769 from [192.168.1.16].2836 > named: error processing update packet id 65281 from [192.168.1.16].2838 > named: Sent NOTIFY for "langstoeger.at IN SOA" (langstoeger.at); 2 NS, 2 A > named: approved AXFR from [192.168.1.2].1751 for "langstoeger.at" > named: zone transfer of "langstoeger.at" (IN) to [192.168.1.2].1751 > named: approved AXFR from [192.168.1.16].2848 for "langstoeger.at" > named: zone transfer of "langstoeger.at" (IN) to [192.168.1.16].2848 > > > Why is NT5 using DDNS update packets which TCPware doesn't understand ? Can't answer that. > Is there a way to trace them better/at-all (except a sniffer) ? You could use TCPDUMP to capture the updates and examine them to see why they're bad. > > Is it TCPware's or M$'s fault ? Will a BIND 9 work ? (TCPIP V5.3 has BIND 9) > Can't tell until you know what is in the updates. > But to top it, NT5 is destroying the domain also: > > A restart (not reload) of the primary gives: > > named: starting. named 8.1.2 for TCPware V5.6-2 > named: Process Software > named: master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 1) > named: master zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2003012601) > named: owner name "gc._msdcs.langstoeger.at" IN (primary) is invalid - rejecting > named: LANGSTOEGER_AT.DB:34: owner name error > named: LANGSTOEGER_AT.DB:34: Database error (A) > named: master zone "langstoeger.at" (IN) rejected due to errors (serial 2003021954) > named: cache zone "" (IN) loaded (serial 0) > named: listening on [192.168.1.3].53 (EWA-0) > named: listening on [127.0.0.1].53 (LPB-0) > named: Forwarding source address is [0.0.0.0].1233 > named: Ready to answer queries. > > btw: a reload doesn't show this problems (but why): > named: Forwarding source address is [0.0.0.0].1229 > named: Ready to answer queries. > > It seems to only work, when you run the NT5 as primary obviously... > > I think the problem is caused by the underscores. You can use - check-names ignore; on the zone to stop the nameserver from rejecting the zone because of these errors. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Fri, 21 Feb 2003 19:03:58 -0400 Date: Sat, 22 Feb 2003 00:01:09 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: Re: [TCPware V5.6-2 = BIND 8.1.2] How to get rid of error messages To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <95z5a.35710$Rb4.474014@news.chello.at> In article <3E563871.7060109@process.com>, Michael Corbett writes: >Peter LANGSTOEGER wrote: >> I've a TCPware BIND server with dynamic updates allowed (to allow a NT5 >> to register its SRV RR itself). >> >> But it doesn't work (as expected ;-) >> >> NT does register some records but not all, because it can't. >> And so periodically there are a lot of OPCOMs. >>[snip] >> Why is NT5 using DDNS update packets which TCPware doesn't understand ? > > Can't answer that. > >> Is there a way to trace them better/at-all (except a sniffer) ? > >You could use TCPDUMP to capture the updates and examine them to >see why they're bad. If I would know what is correct, then I could also find what is wrong. I don't know how M$ SRV RR looks like... I still wonder why its name is TCPDUMP when you can sniff UDP/IP/ICMP also ;-) >> Is it TCPware's or M$'s fault ? Will a BIND 9 work ? (TCPIP V5.3 has BIND 9) Sorry, I forgot to also tell, that TCPIP V5.3 has BIND 9 only on Alpha... >Can't tell until you know what is in the updates. Ok, next time (sorry, not now) I collect some for further investigation... >> But to top it, NT5 is destroying the domain also: >> >> A restart (not reload) of the primary gives: >>[snip] >> btw: a reload doesn't show this problems (but why): >> named: Forwarding source address is [0.0.0.0].1229 >> named: Ready to answer queries. >> >> It seems to only work, when you run the NT5 as primary obviously... > >I think the problem is caused by the underscores. You can use - > >check-names ignore; > >on the zone to stop the nameserver from rejecting the zone because of >these errors. Shame on me. I did know this some years ago. (because I read it, set it up and obviously forget it shortly thereafter - in my previous company)... btw; I've now options { check-names master warn; //instead of fail, becomes ignore later check-names response ignore; check-names slave warn; //will become ignore sometimes too directory "DNS:"; -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Sat, 22 Feb 2003 14:46:53 -0400 Date: Sat, 22 Feb 2003 13:44:14 -0600 (CST) From: Jay Newman Reply-To: Info-TCPware@process.com Subject: Jumbo frames - issues or configuration "gotcha's" ? Sender: Hunter Goatley To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Background : We are running an Open VMS cluster of 2 nodes on Alpha ES40's, using TCPware 5.4-3 . In the last few weeks, we upgraded from 100 BT (DE600) cards to Gigabit (DEGPA-TA). ______________________________________________________ Problem : All other servers on this switch that have been upgraded to Gigabit, fully support jumbo frames (9000 MTU instead of 1500). This includes an identical ES40 with the same type of network adapter (DEGPA-TA.) However, I cannot push the MTU setting much over 7500 without causing a lot of network problems when sending/receiving large files. ______________________________________________________ Question : Has anyone set up TCPware to support jumbo frames, and if so have you found a way to successfully use 9000 MTU instead of around 7500 ? (Yes, the ports on the Cisco switch to which the adapters are connected support jumbo frames and have been configured accordingly.) Regards, Jay Newman ================================================================================ Archive-Date: Sun, 23 Feb 2003 08:19:46 -0400 Date: Sun, 23 Feb 2003 08:17:19 -0500 From: "Main, Kerry" Reply-To: Info-TCPware@process.com Subject: RE: Jumbo frames - issues or configuration "gotcha's" ? To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Jay, What version of VMS? There are a few VMS LAN driver patches that may not be applicable, but should likely be reviewed: http://ftp.support.compaq.com/patches/.new/openvms.shtml Regards Kerry Main Senior Consultant Hewlett-Packard (Canada) Co. Consulting & Integration Services Voice: 613-592-4660 Fax : 613-591-4477 Email: kerryDOTmain@hpDOTcom (remove the DOT's and replace with "."'s) OpenVMS DCL - the original .COM -----Original Message----- From: Jay Newman [mailto:fredthecat@sentex.net]=20 Sent: February 22, 2003 2:44 PM To: info-tcpware@process.com Subject: Jumbo frames - issues or configuration "gotcha's" ? Background : We are running an Open VMS cluster of 2 nodes on Alpha ES40's, using TCPware 5.4-3 . In the last few weeks, we upgraded from 100 BT (DE600) cards to Gigabit (DEGPA-TA). ______________________________________________________ Problem : All other servers on this switch that have been upgraded to Gigabit, fully support jumbo frames (9000 MTU instead of 1500). This includes an identical ES40 with the same type of network adapter (DEGPA-TA.) However, I cannot push the MTU setting much over 7500 without causing a lot of network problems when sending/receiving large files. ______________________________________________________ Question : Has anyone set up TCPware to support jumbo frames, and if so have you found a way to successfully use 9000 MTU instead of around 7500 ? (Yes, the ports on the Cisco switch to which the adapters are connected support jumbo frames and have been configured accordingly.) Regards, Jay Newman ================================================================================ Archive-Date: Sun, 23 Feb 2003 12:43:39 -0400 Date: Sun, 23 Feb 2003 12:40:29 -0500 From: Jay Newman Reply-To: Info-TCPware@process.com Subject: RE: Jumbo frames - issues or configuration "gotcha's" ? Sender: Geoff Bryant To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Hi Kerry. We should be up to date; we are on VMS7.2-2, and reviewed the patch levels a couple of weeks ago with HP. At that time, we applied the OpenVMS VMS722_LAN-V0300 Alpha patch kit. -----Original Message----- From: Main, Kerry [mailto:Kerry.Main@hp.com] Sent: February 23, 2003 08:17 To: info-tcpware@process.com Subject: RE: Jumbo frames - issues or configuration "gotcha's" ? Jay, What version of VMS? There are a few VMS LAN driver patches that may not be applicable, but should likely be reviewed: http://ftp.support.compaq.com/patches/.new/openvms.shtml Regards Kerry Main Senior Consultant Hewlett-Packard (Canada) Co. Consulting & Integration Services Voice: 613-592-4660 Fax : 613-591-4477 Email: kerryDOTmain@hpDOTcom (remove the DOT's and replace with "."'s) OpenVMS DCL - the original .COM