=============================================
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.
|
