* 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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[email protected]> 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?
