* The ANS1946W messages occur because a file whose real name is in that
xxxxx~n.zzz format is trying to be restored, and either another file by
that same name already exists, or a long file name has a short name that
matches that format. If you are restoring to an empty location, you might
try disabling NTFS 8.3 name generation, rebooting, then retrying the
restore. This will suppress generation of short names, and hence those
files should restore. I cannot say whether this is viable for your needs,
but there it is.

For future, consider the ENABLE8DOT3NAMESUPPORT client option if retention
of 8.3 names is important (this must be enabled for backup in order for
the restore to work). You are probably familiar with this already, but I
mention it for completeness.

* The ANS4039E messages suggest corrupted data coming from the server, and
the unnumbered message that precedes each ANS4039E message is related to
that ANS4039E message. I hear you about the unnumbered messages, I would
like to see them go...

* The HlClose() messages indicate an issue with setting security info
(relatively self-explanatory, even if unnumbered). The return code 260
seems related as well, though we'd need to dig deeper to understand what
is going on. If restoring the original security attributes is not
critical, you can try using SKIPNTPERMISSIONS YES for the restore.

You've probably got at least 2 separate issues here (the ANS4039E and the
HlClose messages) that need further investigation. Consider contacting
support with these, and (if you want) tell them that I said these need to
be expedited to Level 2. While 5.1 is no longer supported, it is a design
point that TSM be able to restore files backed up with older client
versions (supported or not). I would think that the HlClose's could be
converted to documented warning (ANSnnnnW) messages, but we also need to
understand the other one about the RC 260. Note that this is just
conjecture on my point, and is not a final diagnosis.

* Questions:

- Is this truly a "cross system restore" issue? What I mean is, can that
same data be restored successfully using 5.1.7.0 on Windows NT 4.0?

- Does the client just stop, or does it crash?

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/08/2007
02:39:41 PM:

> One of our Windows administrators has been attempting a cross-system
> restore using the -virtualnodename option. The system that backed up the
> files was a Windows NT system with 5.1.7.0 client code. The system
> attempting to restore the files is a Windows 2003 system with 5.3.4.3
> client code. The TSM server is a mainframe Linux system with 5.3.4.0
server
> code. The restore restores about seven gigabytes before failing. The
last
> part of the error log is as follows:
>
> 01/08/2007 15:10:06 ANS1946W File
> \\fa001new\e$\Home\jpc101\FY_2002\RADIOL~1.XLS exists, skipping
> 01/08/2007 15:10:09 ANS1946W File
> \\fa001new\e$\Home\jpc101\FY_2002\SURVEY~1.XLS exists, skipping
> 01/08/2007 15:13:14 The 30472th code was found to be out of sequence.
> The code (4025) was greater than (3839), the next available slot in the
> string table.
> 01/08/2007 15:13:14 ANS4039E Error processing
> '\\fa001new\e$\Home\yxl103\mcare\healthpartners03(a).xls': compressed
file
> is corrupted and cannot be expanded.
> 01/08/2007 15:13:14 The 12982th code was found to be out of sequence.
> The code (1771) was greater than (1714), the next available slot in the
> string table.
> 01/08/2007 15:13:14 ANS4039E Error processing
> '\\fa001new\e$\Home\yxl103\mcare\HPCAL02.xls': compressed file is
corrupted
> and cannot be expanded.
> 01/08/2007 15:13:23 HlClose(): Win32 RC 1336 occured restoring NTFS
> Security Attributes on object
> 'E:\Home\yxl103\PO.BOX\MISCFILES\FOXPRO\UVARA20.DBF'.
> 01/08/2007 15:13:23 HlClose(): Default NTFS Security Attributes have
been
> set.
> 01/08/2007 15:13:25 Return code 260 unknown
> 01/08/2007 15:13:25 Unknown system error
> Please check the TSM Error Log for any additional information
>
> The ANS1946W messages shown are the last two of a much larger number
> of such messages. It would appear that original client had a lot of
> files with long names imitating the style of the short names generated
> by Windows.
>
> The TSM messages manual was not particularly helpful, since the TSM
> developers did not see fit to attach message identifiers to most of
> the messages shown above. Web searches for various text strings in
> the messages have so far not turned up anything particularly helpful.
> Does anyone have any suggestions for trouble-shooting this problem?