Andy, Per APAR IC31873, is it implying that for optimal performance the MAXIMUM value of the TCPWindowsize should be 63 on Windows 98, Me, and NT 4.0? By having the TCPWindowsize at a value greater than 63, does it have a negative or positive affect on the restore/ retrieve performance of the client?
Thanks, Demetrius Malbrough UNIX/TSM Administrator -----Original Message----- From: Andrew Raibeck [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 8:21 AM To: [EMAIL PROTECTED] Subject: TSM V4.2.1.20 Windows NT/2000/XP Client Flash ============================================= TSM V4.2.1.20 Windows NT/2000/XP Client Flash ============================================= TSM 4.2.1 was made generally available in September 2001, and we have many customers running it successfully. However, in an effort to give our customers the latest in functional stability for Windows NT-based clients (Windows NT 4.0, Windows 2000, and Windows XP), we are recommending TSM 4.2.1.20 to those who may be affected by the issues described below or who are upgrading to TSM 4.2 for the first time. TSM 4.2.1.20 supercedes both TSM 4.2.0 and TSM 4.2.1 on Windows NT/2000/XP and is our most current level of the TSM client for those operating systems. This 4.2.1.20 Windows NT/2000/XP client patch has gone through some function and system testing. We support its use in a production environment. The client patch can be downloaded from http://www.tivoli.com/support/storage_mgr/clients.html#clients. The main problems addressed by the 4.2.1.20 client patch are: IC31844 - Skipped files causes scheduled backups to be reported as failed Prior to 4.2.1.0, if a scheduled backup had files that were skipped but otherwise ran successfully, the scheduled event would still be reported as successful. This was the correct behavior. With 4.2.1.0, that same scheduled event with skipped files is reported as failed with a return code of 4. The fix in this patch reinstates the correct behavior, which is to report scheduled backups that ran successfully, except for skipped files, as successful. IC31873 - Poor backup performance The backup performance of the 4.2.1.0 client is degraded due to the behavior of a particular system call added in 4.2.1.0. The performance is better when client option TCPWINDOWSIZE 63 (instead of the default 32) is used. However, the patch implements a different system call to work around the problem and restore the previous backup performance. IC32163 - Named Streams restored incorrectly NTFS file systems support multiple data streams in a file. The part of the file that you normally see via Windows Explorer or the DIR command is the unnamed (default) stream. However, some applications also write one or more named (secondary) streams to a file. For example, an application that creates bitmap images might store the main image in the file's default stream, and a "thumbnail" image in a named stream (that is part of the same file). APAR IC32163 concerns itself with named streams. Because named streams are supported only on NTFS file systems, this APAR affects only the Windows NT-based platforms (NT 4.0, 2000, and XP). The Windows 9x-based family (98/Me) are unaffected. Users running the "File Server for Macintosh" service are potentially affected because Windows uses named streams to represent the Macintosh data and resource forks. Users who do not run the "File Server for Macintosh" service are also potentially affected, but to a lesser degree. Whether a particular file has any named streams is dependent on the application that uses the file. The typical NTFS file system (without "File Server for Macintosh" running) has few, if any files containing named streams. There are two named streams issues addressed in this APAR: 1) Named streams are not restored correctly by the 4.2 client if the backup version was created by a 4.1 (or older) client. The files will appear to restore correctly (no TSM warning or error messages), and indeed the default stream (the "main" part of the file) is restored correctly. However the named streams are not restored correctly. This problem affects ALL named streams backed up with a 4.1 (or older) client and restored by a V4.2 client. This problem is fixed in this patch, so named streams backed up by a client older than 4.2 can be correctly restored by the 4.2 client (with exceptions noted in the second issue below). 2) Under very rare boundary conditions, named streams backed up by the 3.7.2.x (up through 3.7.2.18), 4.1.0.x, and 4.1.1.x clients may not have been backed up correctly. During restore, the incorrect named stream data may cause the client to abort a restore operation. This restore problem can happen even with the 4.2 clients. The backup problem was fixed via APAR IC28545 in versions 3.7.2.19, 4.1.2.0, and higher. This problem is fixed in this patch to as great an extent as possible. If a file contains a named stream that was backed up incorrectly, then the following will occur upon a restore with this patch installed: - The default (main) stream will be restored. This is usually the critical part of the file. - A message will be written to the error log file (dsmerror.log) indicating that the file contains, or may contain, a damaged named stream. If any part of the named stream can be restored, it will be restored. Note: A prior patch level, 4.2.1.16, included an early fix for this APAR. It was later determined that the fix was incomplete, and the patch was removed from the FTP site. If you are running 4.2.1.16, then it is strongly recommended that you replace it with the 4.2.1.20 patch. Several smaller changes are also contained in this patch: XP general availability support IC29545 - Windows 2000 RSM database was being backed up, and caused a restore problem. Now TSM doesn't back it up, and skips it during restore. IC31617 - API applications sending 0 length objects could get an error due to copygroup destination. Now TSM doesn't check destination for 0 length objects. IC31706 - DBCS Roman numeral casing problem. Now TSM does correct conversion between codepages for DBCS Roman numerals. IC32171 - The Windows 2000 client never could restore the CLUSTERDB system object during bare metal restore of an entire cluster; it could restore a single cluster node. Now TSM puts CLUSTERDB files in a staging area where they can be restored during a bare metal restore of the whole cluster. IC32281 - Would get an access violation error when attempting to backup a SUBST drive. Now TSM allows the drive to be backed up. IC32412 - When a file can't be accessed by the system for backup (RC=1920), the backup stopped. Now TSM skips the file and continues. Note to users running the "File Server for Macintosh" service: Due to differences in how the 4.2 TSM client stores Mac files on the TSM server versus how prior versions stored Mac files on the TSM server, the 4.2 client may not be able to correctly restore backup versions of Mac files that were created with the pre-4.2 client. Therefore it is strongly recommended that you rename your existing NTFS drives that house Mac files before upgrading to the TSM 4.2 client. If you have already upgraded to the 4.2 client without renaming the existing NTFS drives that house Mac files, then it is strongly recommended that you perform a selective (or full) backup against your NTFS Mac volumes. Since the original delivery of TSM 4.2.1, we have added numerous new quality improvement activities into our development cycle. We are focused on improving quality at every phase of development and will continue to do so release after release. And, in cases where TSM defects escape and reach our customers, we expect that improvements made to the serviceability of TSM will allow us to provide solutions more quickly and painlessly.
