Archive-Date: Tue, 10 Sep 2002 16:55:56 -0400 Date: Tue, 10 Sep 2002 16:55:28 -0400 From: goathunter@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SSH_V553P050 To: tcpware-announce@process.com Message-ID: <00A13C73.5446D0B1.75@triton.process.com> TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: SSH_V553P050 Description: Fix output propblems using SSH command with DCL PIPE Release date: 10-SEP-2002 Ranking: 2 Max ranking: 2 Versions: 5.5-3 ftp://ftp.process.com/support/55_3/ssh_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. ----------------------------------------------------------- ----------------------------------------------------------------------- SSH Patch kit (revision 5.0) for TCPware version 5.5-3 9-Sep-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 8349] - If a remote SSH command is executed as part of a DCL PIPE command: $ pipe ssh remotenode show system | create system.out the output will often contain error messages and only part of the command execution output. 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 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. - [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 [End of ECO announcement] ================================================================================ Archive-Date: Thu, 12 Sep 2002 11:52:09 -0400 Date: Thu, 12 Sep 2002 10:46:28 -0500 From: "Lutes, Dale" Reply-To: Info-TCPware@process.com Subject: NFS: Files not seen by Windows client To: Info-TCPware Message-ID: <3D807084.78A16E5D@cessna.textron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The configuration: TCPware 5.5-3 (both VAX and Alpha). Windows NT and Windows 2000 clients with Reflection Suite for X (versions 7 & 8). I am exporting a file system on my cluster. Most everything can be seen from Windows Explorer, but there are two directories that do not show any files. I've verified the protection and ACLs are the same for files in the "visible" and "invisible" directories. Ditto for the security on the directory files themselves. Everything works fine from a Unix client. It is only Windows that is causing me heartburn. Any suggestions for server parameters that might be tweaked to make this work? Just another example of twisting reliable, properly running systems to make up for flaky Microsoft products. -- Dale D. Lutes ______ Cessna Aircraft Company / ___/_____ _____ _____ ______ ______ One Cessna Boulevard / / / <> // __// __// __ // / Wichita, KS 67215 / /__ / ___//__ //__ // / / // <> / 316-517-7109 /_____//____//____//____//_/ /_//___/_/ ================================================================================ Archive-Date: Thu, 12 Sep 2002 12:12:16 -0400 Date: Thu, 12 Sep 2002 12:06:57 -0400 From: Mike Duffy Reply-To: Info-TCPware@process.com Subject: RE: Files not seen by Windows client To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE860492ADCB@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Barring any simpler answers someone else may soon post, you might try a TCPDUMP: $ NETCU TCPDUMP /SNAP=8192/HEX/RPC=ALL HOST host-name-or-ip We'd be interested in seeing the client issuing READDIR or LOOKUP operations and the server responses to them. This will determine whether the filenames are being reported to the client or whether the requests for those directories are being rejected for some reason. If you're concerned about security, feel free to send the output directly to me at duffy@process.com Please be sure to tell me what filenames and directory names I should be looking for. (Directory listings as seen from both Windows and UNIX clients would help, but the TCPdump should cover the Windows system only). Mike Duffy Process Software > -----Original Message----- > From: Lutes, Dale [mailto:dlutes@cessna.textron.com] > Sent: Thursday, September 12, 2002 11:46 AM > To: Info-TCPware > Subject: NFS: Files not seen by Windows client > > > The configuration: > TCPware 5.5-3 (both VAX and Alpha). > Windows NT and Windows 2000 clients with > Reflection Suite for X (versions 7 & 8). > > I am exporting a file system on my cluster. Most everything > can be seen from Windows Explorer, but there are two directories > that do not show any files. I've verified the protection and > ACLs are the same for files in the "visible" and "invisible" > directories. Ditto for the security on the directory files > themselves. > > Everything works fine from a Unix client. It is only Windows > that is causing me heartburn. Any suggestions for server > parameters that might be tweaked to make this work? Just > another example of twisting reliable, properly running systems > to make up for flaky Microsoft products. > > -- > Dale D. Lutes ______ > Cessna Aircraft Company / ___/_____ _____ _____ ______ ______ > One Cessna Boulevard / / / <> // __// __// __ // / > Wichita, KS 67215 / /__ / ___//__ //__ // / / // <> / > 316-517-7109 /_____//____//____//____//_/ /_//___/_/ > ================================================================================ Archive-Date: Fri, 13 Sep 2002 06:33:38 -0400 Date: Fri, 13 Sep 2002 06:27:44 -0400 (EDT) From: Guy Morris Reply-To: Info-TCPware@process.com Subject: Re: tcpware and csv attachments Sender: Geoff Bryant To: info-tcpware@process.com Message-ID: <014501c25b0b$44a5ce40$cf091ed4@guy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 References: <01KGZ532UB3M8WW0VI@goatley.com> <3CC817C0.8000502@process.com> I am sending out a mail with a word document attached (and that works fine). I'd like to put some text into the body of the mail as well - just to say what the attachment is, and also to be able to make use of the /FROM switch. Can you confirm that I can't do this? Guy. ----- Original Message ----- From: "Michael Corbett" To: Sent: Thursday, April 25, 2002 3:50 PM Subject: Re: tcpware and csv attachments > > Hunter Goatley wrote: > > >>I'm sending the file as: > >> > > > >>MAIL> SEND/NOEDIT/FOREIGN/TYPE=1 ESB_SDL_EXTRACT_MONTH.CSV > >> > > > >>Just to say that I can send .doc files quite happily. > >> > > > > OK. The base64-encoding routines will assume that the file you're > > encoding is binary, and it reads it using RMS block I/O. What you're > > most likely seeing is an normal VMS text file, which on VMS is stored > > on disk with a word at the beginning of each line giving the length of > > that line. RMS hides that from you, but because the file is read in > > block mode, those record length words are being transmitted with your > > file. There's no good way around this except to create your files as > > Stream_LF files so that they're stored without that RMS record > > information. > > > > > > If you have no control over how the file is created you can try converting > it and then send the converted file - > > $ convert/fdl=tcpware:streamlf.fdl - > ESB_SDL_EXTRACT_MONTH.CSV - > converted.csv > $ mail > MAIL> SEND/NOEDIT/FOREIGN/TYPE=1 converted.csv > > 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, 13 Sep 2002 08:40:10 -0400 Date: Fri, 13 Sep 2002 07:34:20 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: tcpware and csv attachments In-Reply-To: "Your message dated Fri, 13 Sep 2002 06:27:44 -0400 (EDT)" <014501c25b0b$44a5ce40$cf091ed4@guy> To: info-tcpware@process.com Message-ID: <01KMG04IY7PK8WW3VM@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 References: <01KGZ532UB3M8WW0VI@goatley.com> <3CC817C0.8000502@process.com> > I am sending out a mail with a word document attached (and that works fine). > I'd like to put some text into the body of the mail as well - just to say > what the attachment is, and also to be able to make use of the /FROM switch. > Can you confirm that I can't do this? Confirmed. You do have the Subject: line for that use, but you can't add another text body part. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ New Robert McCammon novel and site: http://www.RobertRMcCammon.com/ ================================================================================ Archive-Date: Fri, 13 Sep 2002 10:14:32 -0400 Date: Fri, 13 Sep 2002 08:50:18 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: tcpware and csv attachments In-Reply-To: "Your message dated Fri, 13 Sep 2002 07:34:20 -0500 (CDT)" <01KMG04IY7PK8WW3VM@goatley.com> To: info-tcpware@process.com Message-ID: <01KMG3EL0GMO8WW3VM@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 References: <01KGZ532UB3M8WW0VI@goatley.com> <3CC817C0.8000502@process.com> <014501c25b0b$44a5ce40$cf091ed4@guy> > Confirmed. You do have the Subject: line for that use, but you can't > add another text body part. Note, too, that alternative ways of doing this using the VMS MIME utility have been discussed on Info-MultiNet in the past. This method works for TCPware too. The easiest way to do that is to create the messages in a format TCPware expects and then submit them to TCPware SMTP batch queues. Basically, you create the entire file as desired, with all RFC822 headers, then add MAIL FROM, one or more RCPT TO, and ARRIVAL_TIME lines to the top: ------------------------------ MAIL FROM: RCPT TO: RCPT TO: ARRIVAL_TIME: 20-SEP-2000 14:18:00 From: zaius@pota.org To: ursus@pota.org Subject: Military You're going to blow up the world. ------------------------------ Then: $ SUBMIT/QUEUE=TCPWARE_SMTP file.ext Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ New Robert McCammon novel and site: http://www.RobertRMcCammon.com/ ================================================================================ Archive-Date: Fri, 13 Sep 2002 15:40:09 -0400 Date: Fri, 13 Sep 2002 15:33:19 -0400 (EDT) From: Guy Morris Reply-To: Info-TCPware@process.com Subject: Re: tcpware and csv attachments Sender: Geoff Bryant To: info-tcpware@process.com Message-ID: <02c801c25b35$c940d9e0$cf091ed4@guy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 References: <01KGZ532UB3M8WW0VI@goatley.com> <3CC817C0.8000502@process.com> <014501c25b0b$44a5ce40$cf091ed4@guy> <01KMG3EL0GMO8WW3VM@goatley.com> Neat. Not on Info-Multinet so hadn't seen it. Can you forward me a copy/url? Guy. ----- Original Message ----- From: "Hunter Goatley" To: Sent: Friday, September 13, 2002 2:50 PM Subject: Re: tcpware and csv attachments > > > Confirmed. You do have the Subject: line for that use, but you can't > > add another text body part. > > Note, too, that alternative ways of doing this using the VMS MIME > utility have been discussed on Info-MultiNet in the past. This method > works for TCPware too. > > The easiest way to do that is to create the messages in a format > TCPware expects and then submit them to TCPware SMTP batch queues. > Basically, you create the entire file as desired, with all RFC822 > headers, then add MAIL FROM, one or more RCPT TO, and ARRIVAL_TIME > lines to the top: > > ------------------------------ > MAIL FROM: > RCPT TO: > RCPT TO: > ARRIVAL_TIME: 20-SEP-2000 14:18:00 > From: zaius@pota.org > To: ursus@pota.org > Subject: Military > > You're going to blow up the world. > ------------------------------ > > Then: > > $ SUBMIT/QUEUE=TCPWARE_SMTP file.ext > > > > Hunter > ------ > Hunter Goatley, Process Software, http://www.process.com/ > http://www.goatley.com/hunter/ > New Robert McCammon novel and site: http://www.RobertRMcCammon.com/ > > ================================================================================ Archive-Date: Fri, 13 Sep 2002 15:57:01 -0400 Date: Fri, 13 Sep 2002 14:49:46 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: tcpware and csv attachments In-Reply-To: "Your message dated Fri, 13 Sep 2002 15:33:19 -0400 (EDT)" <02c801c25b35$c940d9e0$cf091ed4@guy> To: info-tcpware@process.com Message-ID: <01KMGFD3E8T88WW3VM@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 References: <01KGZ532UB3M8WW0VI@goatley.com> <3CC817C0.8000502@process.com> <014501c25b0b$44a5ce40$cf091ed4@guy> <01KMG3EL0GMO8WW3VM@goatley.com> > Neat. Not on Info-Multinet so hadn't seen it. Can you forward me a > copy/url? Actually, I did some searching and never did find a post that really says more than what I included in that post. You can search the archives using this URL: http://www.multinet.process.com/scripts/mxarchive/as_init.com?Info-MultiNet You can also search Info-TCPware: http://www.multinet.process.com/scripts/mxarchive/as_init.com?Info-TCPware Keywords you might look for are "mime", "submit", "arrival". Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ New Robert McCammon novel and site: http://www.RobertRMcCammon.com/ ================================================================================ Archive-Date: Fri, 20 Sep 2002 09:42:52 -0400 Date: Fri, 20 Sep 2002 09:27:17 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V562P010 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01KMPW3BT9O2001LDY@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: FTP_V562P010 Description: Assorted fixes Release date: 20-SEP-2002 Ranking: 3 Max ranking: 3 Versions: 5.6-2,5.5-3 Requisites: ftp://ftp.process.com/support/56_2/ftp_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. ----------------------------------------------------------- ----------------------------------------------------------------------- FTP Patch kit (revision 1.0) for TCPware version 5.6-2 19-Sep-2002 Copyright (c) 2002 by Process Software Version 1.0 ECO rank: 3 Overall ECO rank: 2 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.6-2 and TCPware V5.5-3 on VMS/VAX V5.5-2 and later, and OpenVMS ALPHA V6.1 and later. The following changes have been made in this kit: - Corrects a problem with the "DIR" command returning the incorrect file size if greater than 2GB. ECO FTP_V562P010, Rank 3 (DE 8279). - Corrects a problem with the "DIR" command in Unix mode returning the incorrect file size if greater than 2GB. ECO FTP_V562P010, Rank 3 (DE 8382). - Updates code to make some error messages in the FTP server more accurate. ECO FTP_V562P010, Rank 3 (DE 8336) - Corrects an ACCVIO caused by using a file with no carriage returns for the TCPWARE_FTP_230_REPLY message. ECO FTP_V562P010, Rank 4 (DE 8237) - Corrects a problem with the PWD command returning an incorrect value if "< >" is used in the default login location in the UAF. ECO FTP_V562P010, Rank 4 (DE 7972) - Corrects a problem with 150 reply messages returning an incorrect value when in Unix mode and with "< >" as part of the default directory specification. ECO FTP_V562P010, Rank 4 (DE 8252) The following changes are included from previous kits. [Please note: the below changes apply only to TCPWare 5.5-3 as they were included in the TCPWare 5.6-2 release. ] 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) - 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 follows: 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 - 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) - 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: Thu, 26 Sep 2002 17:57:20 -0400 Date: Thu, 26 Sep 2002 17:41:16 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SSH_V562P010 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01KMYR2V8GEQ001RR2@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: SSH_V562P010 Description: Assorted Fixes Release date: 26-SEP-2002 Ranking: 2 Max ranking: 2 Versions: 5.6-2 Requisites: ftp://ftp.process.com/support/56_2/ssh_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. ----------------------------------------------------------- ----------------------------------------------------------------------- SSH patch kit (revision 1.0) for TCPware 5.6 25-Sep-2002 Copyright (c) 2002, by Process Software This VMSinstallable saveset provides a new version of the following SSH components: - SSH client (SSH2.EXE) - SSH1 server (SSHD.EXE) - SSH2 server (SSHD2.EXE) - SSH master control program (SSHD_MASTER.EXE) - SSH identity agent program (SSH-AGENT.EXE) - SSH agent identity manipulation program (SSH-ADD.EXE) - SSH file copy client (SCP2.EXE) - SSH file copy servers (SFTP-SERVER2.EXE and SCP-SERVER1.EXE) - SSH server configuration template file (SSHD2_CONFIG.TEMPLATE) This patch is applicable to TCPware SSH 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 problems are addressed by this kit: SSH Server: - [DE 8301] - Not all clients could handle expired passwords. Changed the way they are handled to do a VMS SET PASSWORD command, then log the user out. The user may then log in using the new password. This is consistent with UNIX implementations. Note on SSH and accounts with pre-expired passwords: When a user account has a pre-expired password on the server node, after the user connects to the server and enters the pre-expired password, the process proceeds through SYLOGIN.COM and LOGIN.COM in the process mode "OTHER" not "INTERACTIVE" before being prompted to change the pre-expired password. This could have undesired effects should the SYLOGIN.COM or the LOGIN.COM procedure take action based upon the process mode. (This does not happen when the SYSUAF user login FLAG bit PWD_EXPIRED is set.) - [DE 8306] - The server doesn't time out on connection attempts and will wait forever for a valid ID string, blocking all future connection attempts. - [DE 8432] - The SSH server could hang if the child process it creates terminates within a few seconds of instantiation. - [DE 8424] - When a remote command was executed and DCL VERIFY was enabled after the SYLOGIN.COM and LOGIN.COM files were executed, "$ SET NOON" would appear in the command output. - [DE 8228] - Correct some grammar errors in the SSHD2_CONFIG template file. - [DE 8125] - The SSHD MASTER process didn't check to see if the SSH2 host key existed if SSH2 sessions are enabled. SSH Client - [DE 8311] - If the keyword TryEmptyPassword is used in the SSH2_CONFIG file, the SSH client will exit. - [DE 8445] - A user with BYPASS, SYSPRV or OPER privilege could not forward a privileged (< 1024) local port. The command: $ SSH FOO.COM /LOCAL_FORWARD=(800:LOCALHOST:700) would fail with the error: warning: Tried to forward privileged port 800 as an ordinary user. warning: Local TCP/IP forwarding for port 800 failed. SSH File Transfer - [DE 8410] - When transferring a file via SCP, some line feeds could be missing from the data, destroying the formatting. - [DE 8421] - When transferring a file from a UNIX system running SSH 3.2.0, the following error could be encountered: "FATAL: filexfer_client: bad STATUS (ver 3)" - [DE 8370] - When a "quit" command was executed from OpenSSH SFTP after transferring a file, the session would appear to hang for up to five minutes. NOTE - Although this problem has been corrected, sftp transfers are still not officially supported, even though they may work in many instances. SSH Utilities - [DE 8288] - File names in SSHADD were case-sensitive, resulting in some identity files not being found. Note that the full path of the identity file should be specified when doing a /REMOVE if the current directory is not the directory that the identity file is in. - [DE 8298] - The TCPWARE_SSH_AGENT_ logical wasn't destroyed when the agent terminated, which could cause future login attempts using publickey authentication to fail. The old version of the replaced SSH components will be renamed to TCPWARE_COMMON:[TCPWARE]SSHD.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD_MASTER.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH-ADD.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH-AGENT.EXE_OLD TCPWARE_COMMON:[TCPWARE]SCP.EXE_OLD TCPWARE_COMMON:[TCPWARE]SCP-SERVER1.EXE_OLD TCPWARE_COMMON:[TCPWARE]SFTP-SERVER2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD2_CONFIG.TEMPLATE_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. [End of ECO announcement] ================================================================================ Archive-Date: Sun, 29 Sep 2002 18:31:01 -0400 Date: Sun, 29 Sep 2002 18:29:50 -0400 From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: [TCPware V5.6-2] Timezone anomalies Sender: Geoff Bryant To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: I just upgraded my VS4090 from TCPware V5.5-3 to V5.6-2 and stumbled over the timezone anomalies again. Maybe I'll dig into it some time in the near future but just now I only want to rant ;-) It seems (note: I've not checked and cross-checked) that 1) If TCPWARE_TIMEZONE_NAME is a timezone name not recognized by TCPware (eg. if one enters "MET_DST") it assumes GMT and resets the time to the GMT timezone again and again and again until you deassign the logical at all. 2) TCPwares automatic timezones assume "+0200" is "EET-DST" while it is "MET-DST" or "MET_DST" 3) NETCU still doesn't accept 'SET TIMEZONE "+0200" "MET-DST"' or 'SET TIMEZONE "+0200" "MET_DST"' or 'SET TIMEZONE "+0200" "MET DST"'. It rants with %TCPWARE_NETCU-E-BADPARAM, bad parameter value So I still have to use 'SET TIMEZONE "+0200" "METwDST"' like the last years. Interesting, because if it sets the value automatically, a dash (see EET-DST) is a valid character for the logical, but not for the SET TIMEZONE command... This happens on my VAX. I now have to look for this in my PWS also. In the meantime, does anyone have the right values for TCPWARE_CONFIGURE.COM ? which of the following lines in which combination ? $ NETCU_TIMEZONE == "+0200 METwDST" $ NETCU_TIMEZONE_NAME == "MET_DST" $ NETCU_TIMEZONE_RULES == "Europe/Middle" Anyone ? Martin ? TIA -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm looking for (a) Network _and_ VMS Job(s) ================================================================================ Archive-Date: Sun, 29 Sep 2002 18:39:11 -0400 Date: Mon, 30 Sep 2002 00:36:14 +0200 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: RE: [TCPware V5.6-2] Timezone anomalies In-Reply-To: To: info-tcpware@process.com Message-ID: <001c01c26808$9ef998e0$e6010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter, We have set $ NETCU_TIMEZONE == "+0200" $ NETCU_TIMEZONE_NAME == "MET-DST" $ NETCU_TIMEZONE_RULES == "EUROPE" Endig with the logicals: "TCPWARE_TIMEZONE" = "+020000" = "MET-DST" "TCPWARE_TIMEZONE_NAME" = "MET-DST" "TCPWARE_TIMEZONE_RULES" = "52 5 10 GMT BST WET WET-DST MET MET-DST " = "??? ??? CET CET-DST 1 5 0 1 9 13 0 5 21 25 3600 8 33 37 10800 8 41 " = "45 3600 8 820454400 0 3600 2 512 3600 9 512 3600 631152000 0 3600 2" = " 512 3600 9 789 3600 347155200 0 3600 2 512 3600 9 790 3600 0 0 360" = "0 2 783 3600 9 790 3600 820454400 0 3600 2 512 3600 9 512 3600 3471" = "55200 0 3600 2 512 3600 8 512 3600 0 0 3600 2 512 3600 8 512 3600 8" = "20454400 0 3600 2 512 7200 9 512 7200 347155200 0 3600 2 512 7200 8" = " 512 7200 0 0 3600 2 512 7200 8 512 7200 " Tough, I still _think_ (and do on a regular base) we have to change $ NETCU_TIMEZONE == "+0200" to "+0100". Something that should be clarified IMHO. Timezone processing in POP3 and IMAP4 appears to be fine, so an NTP. V5.6-2 on AXP, OVMS 7.3 -Kurt. -----Original Message----- From: Geoff Bryant [mailto:bryant@process.com] On Behalf Of Peter LANGSTOEGER Sent: Monday, September 30, 2002 12:30 AM To: info-tcpware@process.com Subject: [TCPware V5.6-2] Timezone anomalies I just upgraded my VS4090 from TCPware V5.5-3 to V5.6-2 and stumbled over the timezone anomalies again. Maybe I'll dig into it some time in the near future but just now I only want to rant ;-) It seems (note: I've not checked and cross-checked) that 1) If TCPWARE_TIMEZONE_NAME is a timezone name not recognized by TCPware (eg. if one enters "MET_DST") it assumes GMT and resets the time to the GMT timezone again and again and again until you deassign the logical at all. 2) TCPwares automatic timezones assume "+0200" is "EET-DST" while it is "MET-DST" or "MET_DST" 3) NETCU still doesn't accept 'SET TIMEZONE "+0200" "MET-DST"' or 'SET TIMEZONE "+0200" "MET_DST"' or 'SET TIMEZONE "+0200" "MET DST"'. It rants with %TCPWARE_NETCU-E-BADPARAM, bad parameter value So I still have to use 'SET TIMEZONE "+0200" "METwDST"' like the last years. Interesting, because if it sets the value automatically, a dash (see EET-DST) is a valid character for the logical, but not for the SET TIMEZONE command... This happens on my VAX. I now have to look for this in my PWS also. In the meantime, does anyone have the right values for TCPWARE_CONFIGURE.COM ? which of the following lines in which combination ? $ NETCU_TIMEZONE == "+0200 METwDST" $ NETCU_TIMEZONE_NAME == "MET_DST" $ NETCU_TIMEZONE_RULES == "Europe/Middle" Anyone ? Martin ? TIA -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm looking for (a) Network _and_ VMS Job(s) ================================================================================ Archive-Date: Mon, 30 Sep 2002 21:58:38 -0400 Date: Mon, 30 Sep 2002 21:57:45 -0400 From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: RE: [TCPware V5.6-2] Timezone anomalies Sender: Geoff Bryant To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: In article <001c01c26808$9ef998e0$e6010a0a@home.schumi.ch>, "Kurt A. Schumacher" writes: >We have set > >$ NETCU_TIMEZONE == "+0200" >$ NETCU_TIMEZONE_NAME == "MET-DST" >$ NETCU_TIMEZONE_RULES == "EUROPE" > >Endig with the logicals: > > "TCPWARE_TIMEZONE" = "+020000" > = "MET-DST" > "TCPWARE_TIMEZONE_NAME" = "MET-DST" > "TCPWARE_TIMEZONE_RULES" = "52 5 10 GMT BST WET WET-DST MET MET-DST " > = "??? ??? CET CET-DST 1 5 0 1 9 13 0 5 21 25 3600 8 33 37 10800 >8 41 " > = "45 3600 8 820454400 0 3600 2 512 3600 9 512 3600 631152000 0 >3600 2" > = " 512 3600 9 789 3600 347155200 0 3600 2 512 3600 9 790 3600 0 >0 360" > = "0 2 783 3600 9 790 3600 820454400 0 3600 2 512 3600 9 512 >3600 3471" > = "55200 0 3600 2 512 3600 8 512 3600 0 0 3600 2 512 3600 8 512 >3600 8" > = "20454400 0 3600 2 512 7200 9 512 7200 347155200 0 3600 2 512 >7200 8" > = " 512 7200 0 0 3600 2 512 7200 8 512 7200 " > >Tough, I still _think_ (and do on a regular base) we have to change $ >NETCU_TIMEZONE == "+0200" to "+0100". Something that should be >clarified IMHO. > >Timezone processing in POP3 and IMAP4 appears to be fine, so an NTP. > >V5.6-2 on AXP, OVMS 7.3 Thanks a lot, Kurt. It works. So, now the question is, does one really need all 3 lines ? If yes, then yes, twice a year a modification is required for DST. If not, only one line remains and the other info comes from the system logicals ? Will automatic DST switch then finally work ? Currently I doubt... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm looking for (a) Network _and_ VMS Job(s)