Archive-Date: Thu, 1 Aug 2002 19:00:48 -0400 Date: Thu, 01 Aug 2002 16:54:39 -0600 From: Dan O'Reilly Reply-To: Info-TCPware@process.com Subject: SSH V2 and Expired Passwords To: info-tcpware@process.com Message-ID: <5.1.0.14.2.20020801165418.01c15088@raptor.psccos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed There has been some interest expressed lately in how expired passwords are handled in the SSH server. Some clients such as SecureCRT have no problems with any implementation, while some clients such as PuTTY and OpenSSH will abort with various errors. At issue here is the fact that while expired password handling is actually described in the protocol, it seems to be very much still in a state of flux. The philosophy has been to have the server notify the client that the password needs changing, and the client would do all prompting for old/new passwords and send back the password and status to the server, which would then make the physical change on the system. The problem is that this is one of the areas where the claim of interchangeability of UNIX breaks down, since there are a myriad of different methods for doing so on a UNIX system, let alone for Windows and VMS, for example. Also, not all clients adhered to that standard, and so there have been problems reported with various clients (the so-called "message type 60" errors). So, it appears that at this point, the philosophy seems to be moving toward the idea of having the server ask the host operating system to actually perform password changes, including all prompting as well as making the physical change. To accomplish this, most server implementations will note that a password has expired, then act as if the client had submitted a remote command request as appropriate to force a password change (for example, "/bin/passwd" on UNIX or "SET PASSWORD" on VMS). The operating system will then execute that command and then the server will disconnect the session. The user may then start a new session with the new password. This behavior will be implemented in a future SSH ECO release, the timing of which is not certain at this point, for TCPware 5.6. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "Outside a dog, a book is man's best | | Principal Engineer | friend. Inside a dog, it's too dark | | Process Software | to read." | | http://www.process.com | -- Groucho Marx | +-------------------------------+----------------------------------------+ ================================================================================ Archive-Date: Fri, 2 Aug 2002 14:09:35 -0400 Date: Fri, 02 Aug 2002 13:05:21 -0500 (CDT) From: Lauren Maschio Reply-To: Info-TCPware@process.com Subject: TCPware V5.6 is now shipping Sender: Hunter Goatley To: TCPware-Announce@lists.process.com Message-ID: <01KKTNFQEE2M8WVYKI@goatley.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 TCPware 5.6 is now shipping. Some new features include: - SSH v2 server and client - SCP server and client - NFS v3 server - IPP advanced printing enhancements and utility - SMTP and FTP accounting and statistical reporting - Throughput statistics And more! For more information on this new release, see http://www.process.com/tcpip/tcpware.html. Customers with the maintenance update service will automatically receive TCPware 5.6 by the end of August. ----------------------- Lauren Maschio Process Software Senior Product Manager 959 Concord Road Framingham, MA 01701 (508)626-7525 ----------------------- ================================================================================ Archive-Date: Tue, 6 Aug 2002 11:07:18 -0400 Date: Tue, 06 Aug 2002 11:06:56 -0400 From: goathunter@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SSH_V553P040 To: tcpware-announce@process.com Message-ID: <00A120C1.D74D0822.27@triton.process.com> TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: SSH_V553P040 Description: Fix SSH server for compatability w/ F-Secure 3.1.0 based clients Release date: 6-AUG-2002 Ranking: 2 Max ranking: 2 Versions: 5.5-3 ftp://ftp.process.com/support/55_3/ssh_v553p040.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. ----------------------------------------------------------- ----------------------------------------------------------------------- SSH Patch kit (revision 4.0) for TCPware version 5.5-3 12-Jul-2002 Copyright (c) 2002, by Process Software This VMSinstallable saveset provides a new version of the following SSH components: - SSH server (SSHD.EXE) - SSH client (SSH.EXE) - SSH master control program (SSHD_MASTER.EXE) - SSH control command procedure (SSH_CONTROL.COM) - SSH startup procedure (SSH_STARTUP.COM) This patch is applicable to TCPware 5.5-3 on all supported versions of OpenVMS VAX and OpenVMS Alpha. SSH must be restarted after installation. This ECO has a ranking of 2 - Recommended; individual component may fail. The following problem is addressed by this kit: - [DE 8254] - SSH clients based on the F-Secure 3.1.0 SSH code base will hang when logging into a TCPware 5.5-3 system. These clients include those shipped with TCPware 5.6, SSH for OpenVMS 1.0, and the UNIX versions of this code. The old version of the replaced SSH components will be renamed to TCPWARE_COMMON:[TCPWARE]SSHD.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD_MASTER.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH_CONTROL.COM_OLD TCPWARE_COMMON:[TCPWARE]SSH_STARTUP.COM_OLD Once installed, you may undo this patch by renaming the files back to their original names, and restarting the SSH component. After installing this kit, you must execute the following command to allow the new images to be used: $ @TCPWARE:RESTART SSH Note that this will terminate all current SSH sessions on the system. ------------------------------------------------------------------------ The following problems addressed by previous ECOs are also addressed by this ECO: - [DE 7883] - Line feeds are randomly interjected into the data stream when executing a remote command. - [DE 6612] Under certain conditions, the SSH server will not log messages to OPCOM even though it is supposed to. - [DE 6699] The command SSH /VERSION incorrectly prompts the user for a host name. - [DE 7283] The SSH server identification message incorrectly indicates the server can handle both SSH1 and SSH2 protocols. This will cause many clients to attempt to use the SSH2 protocol, which will subsequently fail. In addition, subsequent versions of SSH for TCPware which follow version 5.5-3 will not be able to successfully connect to SSH on TCPware 5.5-3 for the same reason. - [DE 7789] If an SSH command for remote execution includes a vertical bar character ('|'), the command will usually fail on the remote system. For example, the following command will return a "%DCL-W-MAXPARAM" error when executed remotely on a VMS system: $ ssh foo "pipe show system | search sys$input tcpware" - [DE 7838] On VMS/VAX and VMS/AXP 6.0 and 6.1 systems only, the SSH server and SSH client images will often ACCVIO. - [DE 7598] When executing a remote command via SSH, the output of the command is followed by the output from a LOGOUT/FULL command. The default behavior is now to display only the output from the command to be executed. The old behavior may be restored by defining the following logical name: $ DEFINE/SYSTEM TCPWARE_SSH_COMMAND_OLD_STYLE 1 ================================================================================ Archive-Date: Wed, 7 Aug 2002 18:44:36 -0400 Date: Wed, 07 Aug 2002 18:44:13 -0400 From: goathunter@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V562P010 To: tcpware-announce@process.com Message-ID: <00A121CA.E3A6BCE9.9@triton.process.com> TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V562P010 Description: BSD 4.4 entry points added for UCX$IPC_SHR (for DEC C RTL) Release date: 7-AUG-2002 Ranking: 3 Max ranking: 3 Versions: 5.6-2 ftp://ftp.process.com/support/56_2/drivers_v562p010.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 1.0 for TCPware Version 5.6-2 24-Jul-2002 Copyright (c) 2002 Process Software, LLC Highest ECO Rank 3 Version 1.0 Rank 3 This patch kit provides new versions of the following drivers for TCPware Version 5.6-2: 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) No reboot is necessary for this patch. 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 [End of ECO announcement] ================================================================================ Archive-Date: Wed, 14 Aug 2002 14:10:50 -0400 Date: Wed, 14 Aug 2002 14:10:25 -0400 From: goathunter@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V553P071 To: tcpware-announce@process.com Message-ID: <00A12724.CC6C3342.114@triton.process.com> The following ECO provides a fix for the installation procedure for patches to the FTP component. If you already installed the FTP_V553P070 ECO, then you do not need to install this version of the ECO, but instead you should: $ purge SYS$SPECIFIC:[SYSLIB]TCPWARE_FTPLIB_SHR.EXE $ rename SYS$SPECIFIC:[SYSLIB]TCPWARE_FTPLIB_SHR.EXE - SYS$COMMON:[SYSLIB]TCPWARE_FTPLIB_SHR.EXE Otherwise, please read the information below to determine if this ECO applies to you. ----------------------------------------------------------------------------- TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V553P071 Description: Fix for FTP patch kit installation Release date: 14-AUG-2002 Ranking: 3 Max ranking: 2 Versions: 5.5-3 ftp://ftp.process.com/support/55_3/ftp_v553p071.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. ----------------------------------------------------------- ----------------------------------------------------------------------- FTP Patch kit (revision 7.1) for TCPware version 5.5-3 13-Aug-2002 Copyright (c) 2001, 2002 by Process Software The overall ECO rank: 2 Version 7.1 rank: 3 This VMSINSTALable saveset provides new versions of FTP.EXE, FTP_LISTENER.EXE, and FTP_SERVER.EXE for TCPware for OpenVMS. It applies to TCPware V5.5-3, VMS/VAX V5.5-2 and later, and OpenVMS ALPHA V6.1 and later. The following changes have been made in this kit: TCPWARE_FTPLIB_SHR.EXE - Corrects a problem with previous FTP patches placing TCPWARE_FTPLIB_SHR.EXE in SYS$SPECIFIC:[SYSLIB] instead of the correct location: SYS$COMMON:[SYSLIB]. ECO FTP_V553P071, Rank 3 (DE 8328) IMPORTANT NOTE: -- TCPWARE_FTPLIB_SHR.EXE provides the FTP client API. This problem must be corrected on any system that has applied any of the previous TCPware FTP patches. If this is not corrected, the old version of the API will remain behind on future upgrades and custom FTP API applications may reference the old API instead of the current one since SYS$SPECIFIC:[SYSLIB] is searched before SYS$COMMON:[SYSLIB]. -- This ECO kit will correct this problem by renaming the file TCPWARE_FTPLIB_SHR.EXE in SYS$SPECIFIC:[SYSLIB] left by previous patches to TCPWARE_FTPLIB_SHR.EXE_OLD and place the current version of the file in SYS$COMMON:[SYSLIB]. -- As an alternative to applying this patch, you may correct this problem manually by issuing the following DCL commands: $ purge SYS$SPECIFIC:[SYSLIB]TCPWARE_FTPLIB_SHR.EXE $ rename SYS$SPECIFIC:[SYSLIB]TCPWARE_FTPLIB_SHR.EXE - SYS$COMMON:[SYSLIB]TCPWARE_FTPLIB_SHR.EXE FTP_LISTENER.EXE - Corrects some problems with "ALLOW host [mask]" and "DENY host [mask]" in FTP.CONF file. ECO FTP_V553P070, Rank 3 (DE 8217) - In addition to the information about the FTP.CONF file found in Table 12-1 of the TCPware Management Guide (page 12-3), here are some tips on using the ALLOW and DENY features: o Keep the file short as each line in the file causes additional startup time for the server. o If the REJECT_BY_DEFAULT keyword is used in FTP.CONF, comment out any "DENY" line(s) that are redundant. o If using the "mask" option, comment out any duplicate "ALLOW" or "DENY" lines. For example: If you have a line "ALLOW 26.26.26.100 255.255.255.128", then you do not also need the line "ALLOW 26.26.26.x" in it (where x is 0 to 127) as the mask already covers that host. o Only printable characters are allowed in the REJECT_MESSAGE message and the message size must be less than 255 bytes. ECO FTP_V553P070, Rank 4 (DE 8217) - The FTP listener will no longer default to HIBERNATE when not active. To return to HIBERNATE as the default behavior, define the following logical prior to starting FTP: $ define/sys/exe TCPWARE_FTP_LISTENER_NO_HIBERNATE_OPTION NO ECO FTP_V553P070, Rank 3 (DE 7837) FTP.EXE - Files are once again transferred in alphabetical order. A fix in FTP_V533P062 had caused transfers to occur in reverse alphabetical order although the final outcome was unchanged. ECO FTP_V553P070, Rank 3 (DE 8179) - Corrects an issue with unusually long reply messages causing the TCPware FTP client to hang. ECO FTP_V553P070, Rank 3 (DE 8010) - The TCPware FTP client will no longer insert a carriage return when processing long reply messages from the server. The old behavior was inserting a carriage return every 132 characters. ECO FTP_V553P070, Rank 3 (DE 8010) The following changes are included from previous kits: FTP_LISTENER.EXE - When TCPWARE_FTP_NOKEEPALIVES is defined the FTP server will not send keepalives on the control channel. ECO FTP_V553P040, Rank 3 (DE 6875) - Correct a problem with occasional ftp timeouts. If the symptom still presents after applying the patch, a new logical added in this patch should be used to get rid of the symptom. The logical can be defined as: $ define/system/exe TCPWARE_FTP_LISTENER_NO_HIBERNATE_OPTION TRUE ECO FTP_V553P020, Rank 3 (DE7038) FTP_SERVER.EXE - Allows use of SRI encoding of Unix style file names on ODS-5 disks with the logical TCPWARE_FTP_USE_SRI_ENCODING_ON_ODS5. When this logical is defined to 1, TRUE or YES, the SRI file name encoding used for Unix style file names on ODS-2 disks will be used on ODS-5 disks. This also sets the default case of letters in filenames to lowercase and ignores the stored case. The following logicals should also be defined as shown: TCPWARE_FTP_DISALLOW_UNIX_STYLE FALSE TCPWARE_FTP_UNIX_STYLE_BY_DEFAULT TRUE TCPWARE_FTP_UNIX_STYLE_CASE_INSENSITIVE FALSE TCPWARE_FTP_USE_SRI_ENCODING_ON_ODS5 TRUE ECO FTP_V553P060, Rank 3 (DE 7844) - Corrects some errors in computation for the value returned by MDTM (modification time) for some files. ECO FTP_V553P060, Rank 3 (DE 7855) - The value of TCPWARE_FTP_UNIX_STYLE_CASE_INSENSITIVE is now observed. ECO FTP_V553P060, Rank 3 (DE 7860) - Corrects an ACCVIO that can occur when a file with multiple dots gets a "bad version number" error code. ECO FTP_V553P061, Rank 3 (DE 7912) - Corrects an ACCVIO that can occur when renaming a large group of files. ECO FTP_V553P062, Rank 3 (DE 8000) - Corrects an issue where the LS command displays file names in uppercase. ECO FTP_V553P062, Rank 3 (DE 8051) - Corrects a problem with using FTP's PUT command to transfer files from DOS/WINDOWS. ASCII mode causes the output files to be corrupted if the original file uses LF instead of CRLF to end the lines. ECO FTP_V553P050, Rank 2 (DE 7534) - Corrects a problem with the TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC logical. ECO FTP_V553P050, Rank 3 (DE 7591) - Corrects a potential problem with padding the buffer on the last record of the transferred file. ECO FTP_V553P050, Rank 3 (DE 7756) - Adds a logical TCPWARE_FTP_DISALLOW_WILDCARD_DELETES. Define it to anything to disallow the functionality of accepting wildcards on delete. This may be done at the process, group or system level. (DE 7786) - When TCPWARE_FTP_NOKEEPALIVES is defined the FTP server will not send keepalives on the control channel. ECO FTP_V553P040, Rank 3 (DE 6875) - When the logical TCPWARE_FTP_ADD_CC_ON_FIXED_RECORD_FILES is defined to TRUE and a file is transferred as TYPE IMAGE the FTP server will separate the records of a fixed length record file with the linefeed character. This is useful to avoid the explicit conversion necessary when transferring the file to a non-VMS system with a FTP client that is not able to do record mode transfers. ECO FTP_V553P040, Rank 3 (DE 7272) - Corrects a problem where using put/mput to transfer ASCII files in VMS-PLUS mode causes the output files to contain hundreds of blank trailing spaces. The problem was introduced in patch kit FTP_V55P010. ECO FTP_V553P030, Rank 3 (DE 7318) - Corrects a problem with renaming a file to a destination name containing wildcards (for example rename t.tmp to *.ok). The file would be renamed but the connection was dropped. ECO FTP_V553P030, Rank 3 (DE 7164) - Corrects a problem where the last record is sometimes missing when an image file of fixed length record is transferred. ECO FTP_V553P030, Rank 3 (DE 7331) - Corrects a problem with writing out RECORD (STRU R) files. ECO FTP_V553P010, Rank 3 (DE 6983) - Fill in the resultant file name when an error status is returned due to unsupported I/O operations. (e.g. attempting to RETR a a directory when in Unix mode) ECO FTP_V553P010, Rank 3 (DE 6987) FTP.EXE - Corrects a problem where GET or MGET may fail when there is more than one "." in the file name and the local system is running VMS 7.2-1 or later and the current directory is on an ODS2 disk device. ECO FTP_V553P062, Rank 3 (DE 7915) - Corrects a problem where MGET and MPUT did not preserve the version number order of the transferred files. (ECO FTP_V553P062, Rank 3 (DE 7426) - DIR/FTP and COPY/FTP now support the /PASSIVE qualifier included in the VMS73_DCL-V0200 ECO. ECO FTP_V553P062, Rank 3 (DE 7889) - This kit also provides an informational item below for resolving an ACCVIO problem when transferring a VFC file from VMS 7.3 to non-VMS systems using PUT command. The problem can be resolved by applying the latest VMS FORTRAN RTL ECO (CFAV-FORRTL-V0705-1 from http://www.compaq.com/fortran/downloads.html). ECO FTP_V553P062, Rank 3 (DE 7881) - The KEEPALIVE command allows the FTP client program to toggle whether or not it desires keepalives to be sent on the control channel. The SET [NO]KEEPALIVE command allows the FTP client to explicitly set whether or not it desires keepalives on the control channel. ECO FTP_V553P040, Rank 3 (DE 6875) After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Mon, 26 Aug 2002 10:25:42 -0400 Date: Mon, 26 Aug 2002 10:25:19 -0400 From: goathunter@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V553P041 To: tcpware-announce@process.com Message-ID: <00A13073.570AC124.56@triton.process.com> TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V553P041 Description: Assorted fixes Release date: 26-AUG-2002 Ranking: 3 Max ranking: 1 Versions: 5.5-3,5.4-3 ftp://ftp.process.com/support/55_3/drivers_v553p041.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 4.1 for TCPware Version 5.5-3 14-Aug-2002 Copyright (c) 1999-2000 Process Software Corporation Copyright (c) 2000-2002 Process Software, LLC Highest ECO Rank 1 (Version 3.2) Version 4.1 Rank 2 This patch kit provides new versions of the following drivers for TCPware Version 5.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) 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_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, 27 Aug 2002 16:49:08 -0400 Date: Tue, 27 Aug 2002 14:44:35 -0600 From: "Mah, Lee" Reply-To: Info-TCPware@process.com Subject: TCPWARE vs Compaq TCP/IP To: "'Info-TCPware@process.com'" Message-ID: <42E8EAD18405D311B9D90050047A7170046AEBDD@RANTXCHG01> MIME-Version: 1.0 Content-Type: text/plain When a succession of jobs are submitted for printing to a queue, the default wait time for Compaq TCP/IP is 3 minutes between jobs. This was unacceptable so we have set it to 15 seconds. What is the wait time for a TCPWARE print queue? --- Lee Lee Y T Mah Email: lytmah@cha.ab.ca Capital Health Authority Phone: (780) 477-4725, 477-4233 Information Systems, RAH CSC Fax: (780) 491-5119, 491-5619 10240 Kingsway NW Edmonton, AB, CAN T5H3V9 ================================================================================ Archive-Date: Tue, 27 Aug 2002 17:05:09 -0400 Date: Tue, 27 Aug 2002 17:01:27 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE vs Compaq TCP/IP To: info-tcpware@process.com Message-ID: <3D6BE8A7.4050205@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit References: <42E8EAD18405D311B9D90050047A7170046AEBDD@RANTXCHG01> Mah, Lee wrote: > When a succession of jobs are submitted for printing to a queue, the default > wait time for Compaq TCP/IP is 3 minutes between jobs. This was > unacceptable so we have set it to 15 seconds. What is the wait time for a > TCPWARE print queue? > The default is 15 seconds but it can be controlled by the following logicals - TCPWARE_TSSYM_*_RETRY_INTERVAL Defines the interval at which the symbiont retries to make a connection to a printer after an attempt fails. The format must be D h:mm:ss. The default is 0 0:00:15 (15 seconds delta time). TCPWARE_TSSYM_qname_RETRY_INTERVAL Same as TCPWARE_TSSYM_*_RETRY_INTERVAL, but for a specific queue only, and overrides TCPWARE_TSSYM_*_RETRY_INTERVAL. 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: Tue, 27 Aug 2002 17:17:23 -0400 Date: Tue, 27 Aug 2002 17:13:03 -0400 From: Mike Bartman Reply-To: Info-TCPware@process.com Subject: RE: TCPWARE vs Compaq TCP/IP To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE8604419C17@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 There is no delay built in that I'm aware of. When the queue manager gives the job to the symbiont, it starts working to send it. If you are seeing a delay, tell me which symbiont you are using and I'll check into it further. -- Mike Bartman Process Software bartman@process.com > -----Original Message----- > From: Mah, Lee [mailto:lytmah@cha.ab.ca] > Sent: Tuesday, August 27, 2002 4:45 PM > To: 'Info-TCPware@process.com' > Subject: TCPWARE vs Compaq TCP/IP > > > When a succession of jobs are submitted for printing to a > queue, the default > wait time for Compaq TCP/IP is 3 minutes between jobs. This was > unacceptable so we have set it to 15 seconds. What is the > wait time for a > TCPWARE print queue? > > --- > Lee > > Lee Y T Mah Email: lytmah@cha.ab.ca > Capital Health Authority Phone: (780) > 477-4725, 477-4233 > Information Systems, RAH CSC Fax: (780) > 491-5119, 491-5619 > 10240 Kingsway NW > Edmonton, AB, CAN T5H3V9 > > ================================================================================ Archive-Date: Tue, 27 Aug 2002 17:20:08 -0400 Date: Tue, 27 Aug 2002 15:15:34 -0600 From: "Mah, Lee" Reply-To: Info-TCPware@process.com Subject: RE: TCPWARE vs Compaq TCP/IP To: "'Info-TCPware@process.com'" Message-ID: <42E8EAD18405D311B9D90050047A7170046AEBDE@RANTXCHG01> MIME-Version: 1.0 Content-Type: text/plain According to Michael Corbett, the TCPWARE delay is 15 seconds, same as for Compaq TCP/IP. --- Lee Lee Y T Mah Email: lytmah@cha.ab.ca Capital Health Authority Phone: (780) 477-4725, 477-4233 Information Systems, RAH CSC Fax: (780) 491-5119, 491-5619 10240 Kingsway NW Edmonton, AB, CAN T5H3V9 > ---------- > From: Mike Bartman[SMTP:bartman@process.com] > Reply To: Info-TCPware@process.com > Sent: 27-Aug-02 2:13 PM > To: 'info-tcpware@process.com' > Subject: RE: TCPWARE vs Compaq TCP/IP > > There is no delay built in that I'm aware of. When the queue manager > gives > the job to the symbiont, it starts working to send it. > > If you are seeing a delay, tell me which symbiont you are using and I'll > check into it further. > > -- Mike Bartman > Process Software > bartman@process.com > > > > > -----Original Message----- > > From: Mah, Lee [mailto:lytmah@cha.ab.ca] > > Sent: Tuesday, August 27, 2002 4:45 PM > > To: 'Info-TCPware@process.com' > > Subject: TCPWARE vs Compaq TCP/IP > > > > > > When a succession of jobs are submitted for printing to a > > queue, the default > > wait time for Compaq TCP/IP is 3 minutes between jobs. This was > > unacceptable so we have set it to 15 seconds. What is the > > wait time for a > > TCPWARE print queue? > > > > --- > > Lee > > > > Lee Y T Mah Email: lytmah@cha.ab.ca > > Capital Health Authority Phone: (780) > > 477-4725, 477-4233 > > Information Systems, RAH CSC Fax: (780) > > 491-5119, 491-5619 > > 10240 Kingsway NW > > Edmonton, AB, CAN T5H3V9 > > > > > ================================================================================ Archive-Date: Tue, 27 Aug 2002 17:22:17 -0400 Date: Tue, 27 Aug 2002 17:17:49 -0400 From: Mike Bartman Reply-To: Info-TCPware@process.com Subject: RE: TCPWARE vs Compaq TCP/IP To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE8604419C18@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Those logicals control the delay between connect attempts only when a connection is refused. Whether that is equivalent to a delay between jobs will depend on whether or not the printer/server will accept multiple connections and/or how soon after a job is sent it is ready to accept a connection for the next one. There is no explicit delay between jobs being sent by the TCPware symbionts...they will send it as soon as they can. If the printer will accept them right away, they go right away (allowing time for processing in the symbiont of course). -- Mike Bartman Process Software bartman@process.com > -----Original Message----- > From: Michael Corbett [mailto:corbett@process.com] > Sent: Tuesday, August 27, 2002 5:01 PM > To: info-tcpware@process.com > Subject: Re: TCPWARE vs Compaq TCP/IP > > > Mah, Lee wrote: > > > When a succession of jobs are submitted for printing to a > queue, the default > > wait time for Compaq TCP/IP is 3 minutes between jobs. This was > > unacceptable so we have set it to 15 seconds. What is the > wait time for a > > TCPWARE print queue? > > > > > The default is 15 seconds but it can be controlled by the following > logicals - > > > > TCPWARE_TSSYM_*_RETRY_INTERVAL > > Defines the interval at which the symbiont retries to make a > connection > to a printer after an attempt fails. The format must be D h:mm:ss. The > default is 0 0:00:15 (15 seconds delta time). > > TCPWARE_TSSYM_qname_RETRY_INTERVAL > > Same as TCPWARE_TSSYM_*_RETRY_INTERVAL, but for a specific queue only, > and overrides TCPWARE_TSSYM_*_RETRY_INTERVAL. > > 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: Wed, 28 Aug 2002 10:13:47 -0400 Date: Wed, 28 Aug 2002 10:09:58 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE vs Compaq TCP/IP To: info-tcpware@process.com Message-ID: <3D6CD9B6.70800@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit References: <63D30D6E10CFD11190A90000F805FE8604419C18@lespaul.process.com> Mike Bartman wrote: > Those logicals control the delay between connect attempts only when a > connection is refused. Whether that is equivalent to a delay between jobs > will depend on whether or not the printer/server will accept multiple > connections and/or how soon after a job is sent it is ready to accept a > connection for the next one. There is no explicit delay between jobs being > sent by the TCPware symbionts...they will send it as soon as they can. If > the printer will accept them right away, they go right away (allowing time > for processing in the symbiont of course). > Lee I think the problem you are experiencing is the symbiont finishes one job and then starts another before the first connection is closed at the TCP layer. Most printers will only accept one connection so the second connection gets refused and the symbiont retries 15 seconds later. The logicals I referenced allow you to override the 15 second default retry time and set it according to your needs. 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: Wed, 28 Aug 2002 12:07:36 -0400 Date: Wed, 28 Aug 2002 10:02:57 -0600 From: "Mah, Lee" Reply-To: Info-TCPware@process.com Subject: RE: TCPWARE vs Compaq TCP/IP To: "'Info-TCPware@process.com'" Message-ID: <42E8EAD18405D311B9D90050047A7170046AEBE3@RANTXCHG01> MIME-Version: 1.0 Content-Type: text/plain Thanks for the info. We set the time to 15 seconds for Compaq's TCP/IP stack. Qeueing a series of tasks thru either TCPWARE or HP's TCP/IP takes approx. the same amount of time. --- Lee Lee Y T Mah Email: lytmah@cha.ab.ca Capital Health Authority Phone: (780) 477-4725, 477-4233 Information Systems, RAH CSC Fax: (780) 491-5119, 491-5619 10240 Kingsway NW Edmonton, AB, CAN T5H3V9 > ---------- > From: Michael Corbett[SMTP:corbett@process.com] > Reply To: Info-TCPware@process.com > Sent: 28-Aug-02 8:09 AM > To: info-tcpware@process.com > Subject: Re: TCPWARE vs Compaq TCP/IP > > Mike Bartman wrote: > > > Those logicals control the delay between connect attempts only when a > > connection is refused. Whether that is equivalent to a delay between > jobs > > will depend on whether or not the printer/server will accept multiple > > connections and/or how soon after a job is sent it is ready to accept a > > connection for the next one. There is no explicit delay between jobs > being > > sent by the TCPware symbionts...they will send it as soon as they can. > If > > the printer will accept them right away, they go right away (allowing > time > > for processing in the symbiont of course). > > > > > Lee I think the problem you are experiencing is the symbiont finishes one > job and then starts another before the first connection is closed at the > TCP layer. Most printers will only accept one connection so the second > connection gets refused and the symbiont retries 15 seconds later. The > logicals I referenced allow you to override the 15 second default retry > time and set it according to your needs. > > 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: Thu, 29 Aug 2002 12:23:21 -0400 Date: Thu, 29 Aug 2002 09:12:44 -0700 From: Rob Cervantez Reply-To: Info-TCPware@process.com Subject: SMTP Relaying Question To: info-tcpware@process.com Message-ID: <8EAF526CFB70D611960300508B693073016152@CPQ_NT_SERVER> MIME-Version: 1.0 Content-Type: text/plain What is the earliest version of TCPWare that supports the blocking of relaying using the SMTP_SERVER_REJECT file? Currently: TCPware(R) for OpenVMS V5.3-2 Copyright (c) 1997 Process Software Corporation Platform: VAX/VMS 5.5-2 I don't see any logicals related to SMTP_SERVER_REJECT defined.. Should I? Thanks, Robert. ================================================================================ Archive-Date: Thu, 29 Aug 2002 12:37:17 -0400 Date: Thu, 29 Aug 2002 11:31:57 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: SMTP Relaying Question In-Reply-To: "Your message dated Thu, 29 Aug 2002 09:12:44 -0700" <8EAF526CFB70D611960300508B693073016152@CPQ_NT_SERVER> To: info-tcpware@process.com CC: goathunter@goatley.com Message-ID: <01KLVA27TDTO8WW02V@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii > What is the earliest version of TCPWare that supports the blocking of > relaying using the SMTP_SERVER_REJECT file? If memory serves, it was TCPware V5.4 that included that support. > I don't see any logicals related to SMTP_SERVER_REJECT defined.. Should I? Not necessarily, but you should find a template file with that name (.TEMPLATE) in TCPWARE:. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ New Robert McCammon novel and site: http://www.RobertRMcCammon.com/